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FOREWORD 


This  guide  provides  an  introduction  to  scheduling  intended  for  use  by  government 
program  managers  and  industry  program  of  project  managers  and  their  respective  staffs. 
It  is  the  third  version  of  a  1986  publication  prepared  by  Mr.  David  D.  Acker,  Mr.  J.  Stanley 
Baumgartner,  and  Mr.  Michael  B.  Patterson.  A  second  version,  published  in  1994,  was 
prepared  by  Mr.  William  W.  Bahnmaier  and  Mr.  Paul  T.  McMahon. 

This  version  addresses  many  of  the  topics  contained  in  their  earlier  versions,  especially 
those  relating  to  the  different  types  of  scheduling  techniques.  The  major  difference 
between  this  and  the  previous  versions  is  the  treatment  of  scheduling  as  part  of  the 
acquisition  process  and  the  overall  program  management  effort,  particularly  as  it  relates 
to  the  plaiming  and  control  functions  of  program  management.  Scheduling  is  discussed 
in  the  context  of  the  development  of  integrated  master  plans  and  schedules,  the  risk 
management  process,  and  earned  value  management. 

This  guide  is  not  intended  as  a  detailed  treatment  of  scheduling  techniques.  Instead,  it  is 
more  of  a  primer  on  the  subject,  addressing  the  importance  of  scheduling  and  the 
application  of  basic  scheduling  techniques.  It  is  a  compilation  of  information  from  various 
sources,  and  hopefully  will  serve  as  a  starting  point  for  those  who  desire  to  delve  deeper 
into  the  various  scheduling  techniques. 

The  proliferation  of  microcomputers  has  greatly  enhanced  the  capability  of  managers  at  all 
levels  to  develop  and  analyze  schedules.  Chapter  9  provides  an  overview  of  the  types  of 
automated  tools  available  and  information  on  desirable  features  of  scheduling  software 
applications. 

This  document  reflects  the  efforts  of  many  people.  Mr.  William  W.  Bahnmaier ,  Mr.  Paul 
T.  McMahon  ,  Lt  Col.  David  Bachman,  USAF,  and  Mr.  John  Kelley  of  the  DAU/DSMC 
faculty  provided  invaluable  guidance  and  advice.  Mr.  Gregory  T.  Caruth  of  the  DAU/ 
DSMC  Press  was  very  helpful  in  the  composition  of  the  guide.  Frances  M.  Battle,  provided 
desktop  publishing  skills.  Mr.  Van  Kinney,  Ms.  Joni  Forman  and  Mr.  Tom  Parry  of  the  OSD 
Acquisition,  Resources  and  Analysis  staff  provided  comments  on  the  draft  and  overall 
support  for  the  project.  Special  recognition  also  goes  to  the  Institute  for  Defense  Analysis 
team  of  Mr.  Lou  Simpleman,  Mr.  Jim  Lloyd,  Mr.  George  Tolls,  Ms.  Patti  Phillips,  Ms.  Tina 
Higgins,  and  Ms.  Yolanda  Prescott,  who  wrote,  edited,  and  prepared  the  major  portions 
of  the  text. 


Norman  A.  McDaniel 

Ghair 

Program  Management  and  Leadership 
Department 


William  W.  Bahnmaier 

Editor 
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Department 
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1 

INTRODUCTION 


1.1  OVERVIEW 

In  its  simplest  form,  a  schedule  is  a  listing 
of  activities  and  events  organized  by  time. 
In  its  more  complex  form,  the  process  ex¬ 
amines  all  program  activities  and  their  re¬ 
lationships  to  each  other  in  terms  of  realis¬ 
tic  constraints  of  time,  funds,  and  people, 
i.e.,  resources.  In  program  management 
practice,  the  schedule  is  a  powerful  plan¬ 
ning,  control,  and  communications  tool  that, 
when  properly  executed,  supports  time 
and  cost  estimates,  opens  communications 
among  persoimel  involved  in  program  ac¬ 
tivities,  and  establishes  a  commitment  to 
program  activities. 

A  key  aspect  of  program  management  plan¬ 
ning,  scheduling  is  integral  to  a  program's 
acquisition  strategy  and  to  risk  manage¬ 
ment,  financial,  and  technical  management 
plans.  In  addition,  scheduling  is  an  impor¬ 
tant  element  of  the  other  management  func¬ 
tions:  organizing,  staffing,  controlling,  and 
leading.  For  example,  controlling  is  per¬ 
formed  to  keep  abreast  of  program  execu¬ 
tion.  To  achieve  this  goal,  it  is  necessary  to 
know  whether  the  program  is  behind,  on, 
or  ahead  of  schedule,  and  what  adjust¬ 
ments  are  necessary  to  keep  the  program 
on  schedule  once  it's  back  on  track. 

Why  do  Program  Managers  (PMs)  sched¬ 
ule?  The  simple  answer  is  they  need  a  road 
map  for  all  program  players.  In  reality, 
scheduling  can  accomplish  far  more  than 
providing  a  list  of  activities  and  times. 


Effective  scheduling  supports  the  follow¬ 
ing  key  program  management  activities: 

•  Provides  the  basis  for  effective  com¬ 
munications  within  the  government  team 
and  with  contractors, 

•  Identifies  a  baseline  for  program  status 
monitoring,  reporting,  and  program  control, 

•  Facilitates  management,  and 

•  Provides  the  basis  for  resource  analysis 
and  leveling,  exploration  of  alternatives, 
and  cost/ time  tradeoff  studies. 

On  the  other  hand,  poor  scheduling  can 
adversely  impact  a  program  in  a  number 
of  areas.  Haphazard  schedules  make  it 
difficult,  at  best,  to  determine  a  realistic 
completion  date  and  to  efficiently  allo¬ 
cate  resources  to  the  entire  program.  This 
creates  financial  problems — escalation  of 
costs,  increased  support  costs,  delayed 
return  on  investment,  funding  cuts,  or 
program  termination. 

Since  scheduling  is  a  powerful  plaiming, 
control,  and  communications  tool  avail¬ 
able  for  program  management,  PMs  must 
have  a  good  working  knowledge  of  sched¬ 
uling  practices  and  applications  (such  as 
Gantt,  milestone,  and  network  schedules) 
in  order  to  achieve  program  goals.  PMs 
will  not  always  have  to  construct  detailed 
schedules,  but  they  must  be  able  to  under¬ 
stand  and  analyze  schedules  created  by 
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others  (e.g.,  contractors)  to  successfully 
manage  a  program.  Since  scheduling  is  an 
intrinsic  and  indispensable  element  of  the 
management  process,  it  is  treated  within 
the  context  of  program  management. 

1.2  PURPOSE  OF  THIS  GUIDE 

This  guide  is  an  introduction  to  sched¬ 
uling.  It  is  meant  for  people  who  already 
have  some  experience  in  program  man¬ 
agement  and  those  who  seek  to  learn  more 
about  the  subject.  It  is  not  a  detailed 
treatment  of  the  subject,  but  instead,  ex¬ 
plains  how  scheduling  fits  into  the  overall 
program  management  effort  and  how  to 
accomplish  schedule  plaiming.  It  also  il¬ 
lustrates  different  scheduling  concepts 
and  techniques  and  how  they  can  be  ap¬ 
plied  and  analyzed  to  manage  effectively. 
Finally,  it  is  intended  as  a  road  map  to 
other  useful  and  more  comprehensive 
documents  and  texts  on  the  subjects  of 
project  management,  plaiming,  and  sched¬ 
uling  that  are  available  in  the  literature. 

1.3  GUIDE  CONTENT 

In  order  to  provide  a  suitable  context  for 
the  topic  of  scheduling.  Chapter  2  pro¬ 
vides  an  overview  of  both  program  man¬ 
agement  and  the  acquisition  process  and 
the  role  scheduling  plays  in  each. 

Chapter  3  expands  on  the  role  of  schedul¬ 
ing  in  program  management  and  addresses 
the  following  topics:  work  breakdown 
structure,  integrated  master  plans  and 
schedules,  and  earned  value  management. 
It  concludes  with  a  discussion  of  schedule 
preparation  and  schedule  risk. 

Chapter  4  introduces  the  topic  of  schedul¬ 
ing  techniques  with  a  general  discussion  of 


the  various  types  of  schedules  and  how 
and  why  they  evolved.  This  chapter  is  a 
precursor  for  Chapters  5, 6,  and  7,  which 
present  a  more  detailed  discussion  of 
the  key  schedule  types.  These  chapters 
focus  on  Gantt  and  milestone  schedules, 
network  schedules,  and  production 
schedules. 

Chapter  8  introduces  the  concept  of  time 
management  as  it  relates  to  the  program 
and  to  the  PM.  Chapter  9  presents  the 
subject  of  automated  project  planning  tools 
and  summarizes  some  of  the  desirable  fea¬ 
tures  of  currently  available  software  prod¬ 
ucts.  In  addition  to  an  overview  describing 
the  types  of  automated  tools  available,  this 
chapter  provides  some  suggestions  on  how 
to  find  and  evaluate  the  latest  products. 
The  chapter  concludes  with  a  summary  of 
information  sources  that  will  be  useful  for 
further  inquiry. 

1.4  OTHER  SOURCES  OF  DATA 

As  previously  noted,  this  guide  is  intended 
as  a  primer.  There  is  a  considerable  body  of 
literature  on  the  subject  of  scheduling. 
Much  of  it  is  of  an  academic  nature  not 
specifically  keyed  to  defense  acquisition. 
A  number  of  these  texts  are  listed  in  the 
Bibliography  Appendix  of  this  guide.  Ad¬ 
ditionally,  an  enormous  amount  of  rel¬ 
evant  information  can  be  securedby  search¬ 
ing  the  web  using  some  of  the  popular 
search  engines. 

Of  particular  use  to  PMs  is  the  Defense 
Acquisition  Deskbook,  available  on  the 
Internet  (http:/  /www.  deskbook.  osd.mil). 
The  Deskbook  includes  a  database  contain¬ 
ing  mandatory  and  discretionary  policy 
documents.  Department  of  Defense  and 
component  discretionary  practices,  soft¬ 
ware  tools  and  descriptions,  front-line  wis¬ 
dom  and  advice,  and  sample  formats. 
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PROGRAM  MANAGEMENT  AND 
THE  ACQUISITION  PROCESS 


2.1  PROGRAM  MANAGEMENT 
OVERVIEW 

The  Department  of  Defense  (DoD)  consid¬ 
ers  program  management  to  consist  of  the 
tasks  and  activities  that  must  be  done  in 
order  to  design,  develop,  field,  and  sup¬ 
port  a  weapons  system.  DoD  directives 
describe  an  Acquisition  Program  as:  "A 
directed,  funded  effort  that  is  designed  to 
provide  a  new,  improved,  or  continuing 
weapons  system  or  automated  informa¬ 
tion  system  (AIS)  capability  in  response  to 
a  validated  operational  need."^  DoD  con¬ 
siders  the  "program"  to  include  the  ele¬ 
ments  of  the  acquisition  process,  such  as 
the  plaiming,  programming,  and  budget¬ 
ing  process,  and  the  design,  development, 
and  production  of  the  system.  Practically 
speaking,  a  DoD  program  consists  of  a 
combination  of  organizational  resources, 
assembled  to  create  a  weapons  system  to 
meet  a  specific  operational  requirement. 

Four  key  considerations  typically  involved 
in  a  program  are: 

•  Cost  to  produce  the  system, 

•  Time  required  to  complete  the  effort, 

•  Capability /technical  performance  re¬ 
quired  to  meet  needs,  and 

•  Contribution  of  the  system  to  the  over¬ 
all  defense  operational  and  strategic  plans. 


For  purposes  of  this  guidebook.  Program 
Management  consists  of  the  plaiming,  or¬ 
ganizing,  staffing,  controlling,  and  leading 
(POSCL)  management  functions.  Other 
functions  sometimes  included  in  a  pro¬ 
gram  management  context  are  scheduling, 
budgeting,  monitoring,  directing,  and 
maintaining  consensus  and  support.  For 
this  guidebook,  these  latter  functions  are 
considered  subcategories  of  the  basic  five 
functions,  when  appropriate. 

•  Planning  addresses  the  program  mis¬ 
sion,  objectives,  goals,  and  strategy  and 
includes  all  management  activities  that  re¬ 
sult  in  selection  of  a  course  of  action. 

•  Organizing  considers  the  resources  in¬ 
volved  and  how  are  they  related.  This  func¬ 
tion  addresses  the  alignment  of  people, 
funds,  equipment,  facilities,  etc.,  and  the 
structure  of  the  organization  in  order  to 
meet  program  goals;  it  identifies: 

-  Authority — The  power  to  make  final 
decisions 

-  Responsibility — The  obligation  to  per¬ 
form  assignments 

-  Accountability — The  state  of  being 
answerable  for  the  completion  of  an 
assignment. 

•  Staffing  addresses  the  qualifications 
and  special  skills  that  may  be  required 
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for  persons  assigned  to  each  position  in 
the  program  and  the  time  phasing  of  as¬ 
signments. 

•  Controlling  is  the  function  during  which 
the  manager  monitors,  measures,  evalu¬ 
ates,  and  corrects  program  activities  to  en¬ 
sure  that  actual  operations  conform  to 
plans. 

•  Leading  is  the  process  whereby  one 
individual  exerts  his/her  influence  over 
others  in  a  group.  Directing,  an  element  of 
leadership,  is  the  process  of  implement¬ 
ing,  through  the  talents  of  others,  the  plans 
to  meet  program  objectives.  This  includes 
training,  supervising,  delegating,  motivat¬ 
ing,  counseling,  and  coordinating. 

In  a  broad  sense,  the  planning  phase  in¬ 
cludes  the  tasks  associated  with  defining 
the  work  requirements,  specifying  the  quan¬ 
tity  and  quality  of  work,  identifying  re¬ 
sources,  and  organizing  them  to  best  carry 
out  the  program.  Likewise,  the  manage¬ 
ment  or  execution  phase  includes  the  tasks  of 
monitoring  progress,  comparing  actual  to 
predicted  outcomes,  analyzing  the  impact 
of  differences  between  plaimed  and  actual 
achievements,  and  adjusting  the  program 
as  necessary. 

2.2  THE  EVOLUTION  OF 

PROGRAM  MANAGEMENT 

Formal  program  management  came  to  the 
forefront  in  the  late  1950s.  The  need  to 
develop  and  implement  a  management 
approach  to  manage  large-scale  military 
systems,  both  weapons  and  support  sys¬ 
tems,  stimulated  the  government  and  aero¬ 
space  industry  to  devise  the  means  to  plan 
and  execute  complex  programs.  As  the 
cost  of  weapons  systems  increased  and  the 
intensity  of  the  Cold  War  grew,  DoD  also 


felt  the  need  to  predict  the  cost,  schedule, 
and  performance  of  its  new  systems.  Mili¬ 
tary  organizations  (predecessors  of  cur¬ 
rent  "acquisition"  organizations),  in  conjunc¬ 
tion  with  defense  contractors,  developed 
much  of  the  early  theory  and  practices  of 
program  management  as  new  technolo¬ 
gies  emerged. 

The  use  of  "task  teams"  or  program  teams 
and  other  organizational  entities  led  to  the 
emergence  of  a  program  management  phi¬ 
losophy  for  integrating  activity  in  organiza¬ 
tions.  As  the  program  management  disci¬ 
pline  evolved,  organizations  developed 
special  techniques  for  plaiming,  organiz¬ 
ing,  staffing,  controlling,  and  leading  pro¬ 
grams  to  integrate  those  activities  from  a 
focal  point  in  the  organizational  structure. 
Moreover,  program  management  ad¬ 
dressed  the  elements  of  technical  perfor¬ 
mance,  cost,  and  schedule  on  a  continual 
rather  than  one-time  basis  in  the  evolution 
of  a  program  and  considered  them  within 
the  context  of  an  organization's  operational 
(short-term)  and  strategic  (long-term) 
objectives. 

DoD  has  recently  improved  management 
with  the  introduction  of  the  concept  of 
Integrated  Product  and  Process  Develop¬ 
ment  (IPPD)  and  Integrated  Product  Teams 
(IPTs).  IPPD  integrates  all  acquisition  ac¬ 
tivities  to  optimize  system  development, 
production,  and  deployment.  Key  to  the 
success  of  this  concept  are  the  IPTs,  com¬ 
posed  of  qualified  and  empowered  repre¬ 
sentatives  from  all  appropriate  functional 
disciplines  who  work  together  to  identify 
and  resolve  issues.  IPTs  are  the  founda¬ 
tion  for  program  management.  One  of  the 
tenets  of  IPPD  is  the  use  of  event-driven 
scheduling,  which  relates  program  events 
to  their  accomplishment  and  accomplish¬ 
ment  criteria.  Its  use  reduces  risk  by 
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ensuring  that  product  and  process  matu¬ 
rity  is  incrementally  demonstrated  prior  to 
beginning  follow-on  activities. 

2.3  THE  ACQUISITION  PROCESS 
AND  SCHEDULING 

For  the  management  of  programs,  the  DoD 
acquisition  process  provides  a  framework 
that  consists  of  a  series  of  phases  and  mile¬ 
stones.  The  phases  are  a  logical  means  of 
progressively  translating  broad  mission 
need  statements  into  well-defined  system- 
specific  requirements  and  ultimately  into 
operationally  effective,  suitable,  and  sur- 
vivable  systems.  Each  phase  is  designed, 
among  other  things,  to  manage  / reduce  the 
risks,  ensure  affordability,  and  deliver  the 
system  to  the  user  as  soon  as  possible. 
Milestones  are  the  points  in  time  where 
decision  makers  evaluate  the  status  of  the 
program  and  determine  if  the  program 
should  proceed  to  the  next  phase.  Prudent 
consideration  of  schedule  implications  is 
important  in  all  phases  of  a  program. 

Milestone  Decision  Authority  (MDA)  and 
Service  acquisition  officials  are  encouraged 
to  tailor  programs  to  eliminate  phases  or 
activities  that  result  in  little  payoff  in  terms 
of  fielding  time  or  cost.  To  effectively 
tailor  a  program,  managers  must  under¬ 
stand  scheduling,  resource  availability  and 
allocation,  and  the  risk  associated  with  the 
tailoring. 

An  acquisition  strategy  defines  the  busi¬ 
ness  and  technical  management  approach 
to  meet  objectives  within  schedule  and 
program  constraints.  A  primary  goal  is  to 
minimize  the  time  and  cost  of  satisfying  a 
valid  need,  consistent  with  common  sense 
and  sound  business  practices.  A  PM  pre¬ 
pares  a  preliminary  acquisition  strategy  at 
Milestone  0  and  updates  the  strategy  to 


support  each  milestone  decision  by  de¬ 
scribing  activities  and  events  planned  for 
the  upcoming  phase  and  relating  the  ac¬ 
complishments  of  that  phase  to  the 
program's  overall,  long-term  objectives. 
The  acquisition  strategy  is  first  formally 
approved  and  published  at  MSI,  Program 
Initiation.  It  provides  a  master  schedule  for 
research,  development,  test,  production, 
fielding,  and  other  activities  essential  to 
program  success.  This  master  schedule 
also  serves  as  the  basis  for  formulating 
functional  plans  and  schedules. 

As  a  program  evolves  through  subsequent 
phases,  new  information  becomes  avail¬ 
able  that  permits  refinement  of  schedules 
and  assignment  of  resources.  Understand¬ 
ing  of  program  risk  becomes  more  specific 
as  the  system  under  development  is  de¬ 
fined,  thereby  allowing  identification  of 
risk-handling  initiatives  and  their  effect  on 
schedule.  Schedule  considerations  are  an 
integral  part  of  any  Source  Selection  pro¬ 
cess,  from  preparation  of  the  Request  for 
Proposal  (RFP)  through  proposal  evalua¬ 
tion.  After  contract  award,  the  schedule 
serves  as  a  basis  to  determine  progress  and 
assess  the  need  for  management  action. 

Government  developers  should  design  their 
contracts  with  industry  to  allow  time  for 
milestone  decisions,  permit  demonstration 
of  exit  criteria  in  time  to  support  milestone 
reviews  and  to  reflect  expenditure  of  money 
with  the  program's  funding  profile.  A  good 
acquisition  strategy  allows  fiscal  control 
without  delaying  the  acquisition  decisions 
or  contracts  while  adequately  considering 
risk.  In  other  words,  it  reflects  thoughtful 
schedule  and  resource  planning. 

As  a  key  element  of  the  planning  proess,  PMs 
must  update  the  schedule  as  more  is  learned 
about  the  program  and  as  changes  occur. 
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With  each  new  update,  program  cost,  time, 
and  requirements  may  change.  PMs  must 
respond  by  changing  the  mix  and  level  of 
resources  and  continuously  updating  the 
program  plan  and  the  schedule  as  needed. 

2.4  RISK  MANAGEMENT  AND 
SCHEDULING 

DoD  defines  risk  management  as  "the  act 
or  practice  of  controlling  risk.  It  includes 
risk  plaiming,  assessing  risk  areas,  devel¬ 
oping  risk-handling  options,  monitoring 
risks  to  determine  how  risks  have  changed, 
and  documenting  the  overall  risk  manage¬ 
ment  program.  As  part  of  their  responsi¬ 
bility  to  manage  risk,  PMs  must  consider 
risk  in  their  plaiming  and  scheduling  prac¬ 
tices.  Risk  management  is  concerned  with 
the  identification  of  uncertainties  that 
threaten  cost,  schedule,  and  performance 
objectives,  and  the  development  and  imple¬ 
mentation  of  actions  to  best  deal  with  those 
uncertainties. 


Risk  management  and  scheduling  are 
closely  tied.  Consideration  of  one  requires 
a  reassessment  of  the  other.  For  example, 
in  creating  the  strategy  and  plans  to  handle 
program  risk,  a  PM  must  con¬ 
sider  how  the  approach  affects  the  pro¬ 
gram  schedule.  Similarly,  any  tradeoffs 
between  cost  and  performance  must  take 
into  account  schedule  implications.  Con¬ 
versely,  any  change  to  the  program  sched¬ 
ule  must  consider  the  impact  on  the  overall 
program  objectives  and  on  cost  and  perfor¬ 
mance.  The  challenge  is  to  develop  a  plan 
that  balances  risk,  cost,  schedule,  and  per¬ 
formance. 

Schedule  risk  is  defined  as  the  likelihood 
and  consequences  of  failing  to  meet  the 
program  schedule,  and  it  is  an  integral  part 
of  program  risk.  This  topic  is  covered  in 
Chapter  3. 


ENDNOTES 


DoDD  5000.1,  Defense  Acquisition,  March  15, 1996.  (Being  revised  and  updated  as  of  1  January  2000) 
Ibid. 


6 


3 

PROGRAM  MANAGEMENT  AND  SCHEDULING 


As  discussed  in  the  previous  chapters, 
scheduling  is  one  of  the  most  powerful 
tools  available  to  the  PM,  and  its  effective 
application  is  essential  to  program  suc¬ 
cess.  While  it  is  a  key  element  in  perform¬ 
ing  all  program  management  functions,  it 
is  also  critical  to  the  accomplishment  of 
planning  and  controlling  management 
functions.  This  chapter  discusses  schedul¬ 
ing  in  the  context  of  these  two  functions 
and  addresses  the  essential  elements  and 
considerations  in  schedule  plaiming. 

3.1  PROGRAM  PLANNING  AND 
SCHEDULING 

Program  plaiming  is  the  process  of  deter¬ 
mining  what  needs  to  be  accomplished,  by 
whom,  when,  and  under  what  resource 
constraints.  It  is  arguably  the  most  impor¬ 
tant  of  the  program  management  functions. 
Without  a  sound  and  comprehensive  plan, 
it  is  virtually  impossible  to  develop  a  mean¬ 
ingful  budget,  effectively  organize  and  staff 
the  program  office,  direct  the  actions  of  the 
program  office,  or  monitor  and  control  the 
program.  In  addition  to  determining  the 
"what,  where,  who,  with  what,  and  when" 
of  a  program,  planning  also  helps  to  iden¬ 
tify  risk  areas  and  ways  to  handle  the  risk, 
and  establishes  the  program  baselines. 

There  are  a  number  of  products  of  the 
planning  process.  Among  them  are: 

•  Acquisition  Strategy — This  is  the  com¬ 
prehensive,  integrated  plan  the  program 
will  follow.  It  provides  an  overall  concept 


of  the  program  that  functional  plans  will 
lay  out  in  greater  detail  and  reflects  the 
strategy  that  will  be  followed  to  meet  pro¬ 
gram  objectives  and  to  handle  risk  in  the 
program.  The  acquisition  strategy  in¬ 
cludes  a  program  structure /schedule 
which  depicts  a  visual  overview  and  pic¬ 
ture  presentation  of  the  acquisition  strat¬ 
egy.  This  schedule  is  a  single  diagram 
similar  to  the  diagram  shown  in  Figure  3-3, 
and  defines  the  relationship  among  acqui¬ 
sition  phases,  decision  milestones,  solici¬ 
tations,  contract  awards,  systems  engineer¬ 
ing  design  reviews,  contract  deliveries,  test 
and  evaluation  activities,  production  re¬ 
leases,  and  operational  deployment  objec¬ 
tives.  It  includes  quantities  to  be  procured 
and  delivered  by  fiscal  year  by  phase  in 
terms  of  prototypes,  engineering 
de  velopmemt  models,  low-rate  intitial  pro¬ 
duction  and  full-rate  production.  The  pro¬ 
gram  structure/ schedule  is  a  key  decision 
review /milestone  document;  it  summa¬ 
rizes  the  program  and  is  built  from  many 
other  more  detailed  schedules  found  in 
functional  plans  such  as  test  and  evalua¬ 
tion,  contracting,  etc.  It  is  sometimes  re¬ 
ferred  to  as  the  Master  Program  Schedule 
(MPS).  In  addition  to  this  top  level  struc¬ 
ture/  schedule,  the  PM  may  deem  it  neces¬ 
sary  to  have  more  detailed  program  man¬ 
agement  Integrated  Master  Plans  (IMP)  and 
Integrated  Master  Schedules  (IMS)  pre¬ 
pared  and  submitted  by  the  contractor 
during  the  proposal  process.  See  the  DSMC 
Acquisition  Strategy  Guide^  for  information 
on  structuring,  developing,  and  executing 
an  acquisition  strategy. 
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•  Functional  Plans — These  are  the  de¬ 
tailed  plans  that  lay  out  the  approach  to 
be  taken  in  the  different  functional  areas. 
Examples  include:  the  Test  and  Evalua¬ 
tion  Master  Plan  (TEMP)  and  Command, 
Control,  Communications,  Computers,  and 
Intelligence  (C4I)  Support  Plan,  which  are 
required;  and  the  Systems  Engineering 
Master  Plan  (SEMP),  Logistics  Support 
Plan  (ESP),  etc.,  which  are  optional. 

•  Work  Breakdown  Structure  (WBS) — 

The  WBS  provides  a  basic  framework  for 
identifying  each  element  of  a  project  in 
increasing  levels  of  detail.  In  essence,  it 
describes  the  way  work  is  performed.  The 
WBS  also  provides  a  coherent  method  for 
reporting  progress  toward  plan  goals. 

•  Integrated  Master  Plan  (IMP) — The 

IMP  is  an  event-based  plan  depicting  the 
overall  structure  of  the  program  and  the 
key  processes,  activities,  and  milestones. 
It  defines  accomplishments  and  criteria  for 
each  event. 

•  Integrated  Master  Schedule  (IMS) — 

The  IMS  shows  the  detailed  tasks  and 
timing  for  events  in  the  IMP  and  depicts 
the  logical  progression  of  events  through¬ 
out  the  program.  These  tasks  should  be 
directly  traceable  to  the  IMP  and  the  WBS. 

•  Schedules — A  series  of  schedules  are 
developed  during  the  planning  process, 
all  of  which  are  derived  from  the  IMS. 
These  schedules  are  developed  to  show 
the  details  required  to  complete  key  activi¬ 
ties  and  milestones. 

•  Budget — The  budget  reflects  the  cost 
of  the  integration  of  the  scope,  schedule, 
and  resource  plan  for  accomplishing  the 
work. 


Scheduling  is  a  critical  element  in  the  plan¬ 
ning  process.  In  addition  to  being  an  out¬ 
put  of  the  process  as  discussed  above,  it 
also  contributes  to  the  development  of  the 
other  outputs.  The  early  involvement  of 
people  who  are  knowledgeable  and  experi¬ 
enced  in  scheduling  techniques  can  contrib¬ 
ute  to  the  effective  translation  of  strategic 
concepts  and  ideas  into  detailed  logic  dia¬ 
grams,  depicting  the  program  activities 
and  relationships  among  activities.  This 
can  be  very  useful  in  developing  budget 
and  detailed  functional  plans,  especially 
in  identifying  the  required  resources  and 
leveling  them  throughout  the  activities. 

The  WBS  and  the  IMP/IMS  are  important 
concepts  used  in  the  scheduling  process 
and  are  described  in  more  detail  in  the 
following  sections. 

3.2  WORK  BREAKDOWN  STRUCTURE 

During  the  1960s,  the  impetus  to  develop  a 
tool  to  help  project  managers  define  a 
project  in  a  cohesive  way  gave  rise  to  the 
development  of  the  WBS.  WBS  use  has  not 
been  confined  to  the  DoD  and  its  contrac¬ 
tors;  rather,  it  is  now  used  in  many  com¬ 
mercial  enterprises.  Several  years  after  the 
emergence  of  the  WBS  concept,  DoD  pub¬ 
lished  a  WBS  standard  for  DoD  acquisition 
organizations  as  well  as  their  contractors  to 
use:  MIL-STD-881B.  This  standard  has  been 
superseded  by  a  handbook,  MIL-HDBK- 
881,  dated  2  January  1998.  It  contains  much 
of  the  same  information  as  its  predecessor 
but  is  not  directive  in  nature  and  is  for 
guidance  only. 

MIL-HDBK-881defines  a  WBS  as: 

•  A  product-oriented  family  tree  com¬ 
posed  of  hardware,  software,  services,  data, 
and  facilities.  The  family  tree  results  from 
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Figure  3-1 .  Generic  Aircraft  System  Program  WBS 


systems  engineering  efforts  during  the  ac¬ 
quisition  of  a  defense  materiel  item. 

•  A  WBS  displays  and  defines  the  prod¬ 
uct,  or  products,  to  be  developed  and/or 
produced.  It  relates  the  elements  fo  work 
to  be  accoomplished  to  each  other  and  to 
the  end  product. 

•  A  WBS  can  be  expressed  down  to  any 
level  of  interest.  However,  the  top  three 
levels  are  as  far  as  any  program  or  contract 
needs  to  go  unless  the  items  identified  are 


high  cost  or  high  risk.  In  that  case,  the  WBS 
should  be  taken  to  a  lower  level  of 
definition. 

WBS's  apply  to  seven  specific  categories  of 
defense  materiel  systems:  aircraft;  elec¬ 
tronic/  automated  software;  missile,  ord¬ 
nance;  ship;  space;  and  surface  vehicle. 
The  WBS  should  be  developed  and  main¬ 
tained  based  on  the  systems  engineering 
efforts  throughout  the  system's  life  cycle. 

Figure  3-1  is  an  example  of  a  level  3  program 
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Requirement 

WBS  Elements 

SOW  Task 

WBS  for  an  aircraft  system.  The  WBS  ap¬ 
proach  provides  a  powerful  technique  for 
scoping  a  project  in  a  manner  that  provides 
management  with  insight  into  project  re¬ 
quirements  and  performance — ^from  the 
very  top,  or  systems  level,  to  the  lowest 
level  of  definition  of  a  work  product.  Plan¬ 
ning  work  using  the  WBS  approach  serves 
as  the  basis  for  both  estimating  and  sched¬ 
uling  resource  requirement. 

3.2.1  Integrated  Master  Plans/ 

Schedules 

The  IMP  is  a  very  effective  tool  of  program 
management.  It  is  the  contractor's  event- 
based  plan  for  accomplishing  the  State¬ 
ment  of  Objectives  (SOO)  and  Statement  of 
Work  (SOW).  It  identifies  the  key  activi¬ 
ties,  events,  milestones,  and  reviews  that 
make  up  the  program.  A  program  IMP  is 
prepared  initially  by  the  contractor  and 


provides  the  basis  for  development  of  sub¬ 
ordinate  IMPs  and  other  functional  plans. 
It  also  identifies  those  events  and  activities 
that  will  be  included  in  the  IMS. 

The  IMS  is  a  networked  multi-layered 
schedule  generated  by  the  contractor  that 
begins  with  all  identified  IMP  events,  ac¬ 
complishments,  and  criteria.  It  shows  the 
expected  start  and  finish  dates  of  these 
events.  It  contains  all  contractually  re¬ 
quired  events  /  milestones  such  as  reviews, 
tests,  completion  dates,  and  deliveries 
specified  in  the  program  WBS. 

The  IMP  is  prepared  by  the  contractor 
during  the  proposal  process.  It  is  main¬ 
tained  by  the  government  program  office 
and  contractor  through  a  collaborative  ef¬ 
fort  involving  all  the  program  "stakehold¬ 
ers."  In  some  cases,  a  preliminary  IMP 
may  be  developed  by  the  government. 


10 


with  industry  input,  during  pre-solicita¬ 
tion.  The  IMP  defines  contract  requirements 
stated  in  the  RFP  and  contractors  use  it  to 
develop  the  IMS  and  detailed  functional 
schedules.  These  integrated  schedules  tie 
together  all  program  tasks  by  showing  their 
logical  relationships  and  any  constraints 
controlling  the  start  or  finish  of  each  task. 
This  process  results  in  a  hierarchy  of  re¬ 
lated  functional  and  layered  schedules 
derived  from  the  WBS  that  can  be  used  for 
monitoring  and  controlling  program 
progress.  An  example  (suggested  format) 
of  an  IMP  /  IMS  for  an  aircraft  development 
program  is  depicted  in  Figure  3-2.  The  IMS 
should  be  expanded  down  to  the  level  of 
detail  appropriate  for  the  scope  and  risk  of 
the  program.  Programs  with  high  risk 
should  show  more  detail  in  the  IMS  to 
provide  the  visibility  necessary  to  manage 
risk.  A  more  detailed  discussion  of  IMS's  is 
contained  in  Appendix  A.  A  Data  Item 
Decription  (DID)  has  been  developed  by  the 
Department  of  Defense  for  the  IMS ;  the  iden¬ 
tification  number  is  DTMISC-81183A.  This 
DID  is  at  Tab  1  to  Appendix  A. 

3.3  PROGRAM  CONTROLLING 
AND  SCHEDULING 

The  controlling  function  contains  all  those 
activities  that  a  program  manager  under¬ 
takes  in  attempting  to  ensure  that  the  ac¬ 
tual  program  conforms  to  the  developed 
plan,  to  include  the  implementation  of  nec¬ 
essary  action  to  get  the  program  back  on 
the  plan  if  possible.  To  control  a  program, 
the  PM  needs  the  means  to  monitor  pro¬ 
gram  progress  against  the  established  plan, 
or  the  program  baseline.  In  its  simplest 
form,  the  program  schedule  can  serve  as  a 
baseline  against  which  to  measure  progress. 
If  there  are  indications  that  an  activity  is 
falling  behind  schedule,  this  information 
can  be  used  by  the  manager  as  a  basis  for 


corrective  action.  However,  considering 
schedule  information  alone  can  be  mis¬ 
leading.  Successful  management  requires 
the  integration  of  the  technical,  schedule, 
and  cost  aspects  of  a  program.  Thus,  some 
form  of  integrated  performance  measure¬ 
ment  is  needed  for  monitoring  and  control¬ 
ling  a  program.  The  concept  of  earned  value 
management  provides  such  a  capability. 

3.3.1  Earned  Value  Mangement 

Earned  Value  Management  (EVM)  is  the 
use  of  an  integrated  management  system 
that  coordinates  work  scope,  schedule,  and 
cost  goals  and  objectively  measures  pro¬ 
gress  toward  these  goals.^  The  purpose  of 
EVM  is  to  provide  contractor  and  gov¬ 
ernment  PMs  with  accurate  data  to  moni¬ 
tor  program  execution.  It  is  also  intended 
to  provide  an  adequate  basis  for  sound 
contractor  and  government  decision  mak¬ 
ing  by  requiring  that  the  contractor's  inter¬ 
nal  management  control  systems  produce 
data  that:  (1)  indicate  work  progress;  (2) 
properly  relate  cost,  schedule,  and  techni¬ 
cal  accomplishments;  (3)  are  valid,  timely, 
and  able  to  be  audited;  and  (4)  provide 
DoD  component  managers  with  informa¬ 
tion  at  a  practical  level  of  summarization. 

The  DoD  earned  value  process  holds  the 
contractor  responsible  for  effective  imple¬ 
mentation  of  an  EVM  system.  DoD  does  not 
prescribe  a  specific  EVM  system  for  con¬ 
tractors  to  use;  instead,  it  has  established  a 
set  of  criteria  that  the  contractors'  systems 
must  meet  to  be  acceptable.  The  require¬ 
ment  to  use  an  EVM  system  that  meets  the 
criteria  is  dependent  on  the  type  and  size 
of  the  contract.  DoD  Regulation  5000.2-R 
defines  the  contracts  that  must  use  such  an 
EVM  system  as  well  as  the  criteria  for  an 
acceptable  system.  For  contracts  that  do 
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not  meet  these  thresholds,  contractor  man¬ 
agement  information  is  provided  to  the 
government  using  a  Cost/ Schedule  Status 
Report  (C/SSR).  This  report  should  be 
based  on  an  underlying  management  sys¬ 
tem  that  uses  an  earned  value  approach  for 
tracking  progress.  Such  a  system  does  not 
have  to  meet  the  EVM  criteria  of  DoD 
5000. 2-R;  however,  the  government  should 
negotiate  with  the  contractor  to  ensure  that 
the  system  does  emphasize  earned  value 
methodology. 

Basically,  earned  value  relates  resource 
plaiming  to  schedules  and  to  technical  per¬ 
formance  requirements.  All  work  (identi¬ 
fied  in  the  Program  and  Contract  Work 
Breakdown  Structures)  is  plaimed,  bud¬ 
geted,  and  scheduled  in  time-phased 
"plaimed  value"  increments  constituting  a 
performance  measurement  baseline.  As 
work  is  performed,  it  is  "earned"  on  the 
same  basis  as  it  was  planned,  e.g.,  in  bud¬ 
geted  dollars  or  labor-hours.  Planned  value 
[budgeted  cost  of  work  scheduled  (BCWS)] 
compared  with  earned  value  [budgeted  cost 
of  work  performed  (BCWP)]  measures  the 
dollar  volume  of  work  planned  versus  the 
equivalent  dollar  value  of  work  accom¬ 
plished.  The  difference,  if  any,  is  termed 
the  "schedule"  or  "accomplishment"  vari¬ 
ance.  Earned  value  (BCWP)  compared 
with  the  actual  cost  of  the  work  performed 
(ACWP)  provides  an  objective  measure¬ 
ment  of  cost  performance.  Any  difference 
is  called  the  cost  variance. 

The  three  data  points — BCWS,  BCWP,  and 
ACWP — are  outputs  of  the  EVM  system  and 
are  provided  to  the  government  on  a  monthly 
basis.  They,  along  with  the  schedule  and  cost 
variances,  provide  the  basic  information 
needed  to  determine  program  status  at  a 
given  time,  and  to  identify  the  elements  that 
are  driving  each  of  the  variances. 


Analysis  of  these  data  points  over  time 
also  identifies  trends  that  may  affect  or 
impact  the  future  performance  for  the  re¬ 
mainder  of  the  contract.  This  is  important; 
it  enables  PMs  to  isolate  causes  of  recur¬ 
ring  variations  and  to  take  alternative  ac¬ 
tions  that  will  improve  performance.  Quan¬ 
titative  techniques  can  also  be  applied  to 
EVM  data  to  predict  program  performance 
at  completion  in  terms  of  cost  and  sched¬ 
ule.  The  DSMC  EVM  Textbook^  provides 
detailed  information  on  the  application  of 
EVM  techniques. 

Success  of  EVM  techniques  is  dependent  on 
several  things,  not  the  least  of  which  is 
effective  and  accurate  contractor  schedul¬ 
ing.  EVM  system  criteria  do  not  require 
contractors  to  use  specific  scheduling  tech¬ 
niques.  However,  they  do  seek  formality, 
consistency,  and  discipline  throughout  the 
scheduling  process.  The  contractor's  sched¬ 
uling  system: 

•  Provides  a  summary  or  master  sched¬ 
ule  and  related  subordinate  schedules 
showing  vertical  traceability  from  the  mas¬ 
ter  to  the  detailed  schedules 

•  Identifies  key  milestones  and  activities 
and  indicates  significant  constraints  and 
relationships 

•  Provides  current  status  and  forecast  of 
completion  dates  of  scheduled  work  that 
enable  comparison  of  planned  and  actual 
status  of  program  accomplishments 

•  Establishes  a  schedule  baseline 

•  Provides  horizontal  traceability  show¬ 
ing  interrelationships  among  various  ac¬ 
tivities. 


12 


The  scheduling  baseline  usually  con¬ 
sists  of  a  hierarchy  of  vertically  inte¬ 
grated  schedules,  with  each  lower-level 
schedule  more  fully  identifying  and  ex¬ 
panding  the  tasks  necessary  to  meet  the 
program's  objectives.  Generally,  three  sets 
of  schedules  are  prepared: 

•  Master  Schedule  (MS) — The  top-level 
schedule  that  summarizes  key  program 
activities  and  milestones  and  depicts  the 
logical  progression  of  events  throughout  a 
contract.  Program  Structures/Master  Pro¬ 
gram  Schedules  developed  by  the  govern¬ 
ment  PM  reflect  information  contained  in 
the  contractor's  Master  Schedule. 

•  Intermediate  Schedules — The  sched¬ 
ule  that  ties  the  MS  to  the  detailed  sched¬ 
ules.  It  allows  for  rollup  of  detailed  sched¬ 
ules  to  summary  levels  that  are  useful  for 
management. 

•  Detailed  Schedules — The  schedules  at 
the  control  account  or  work  package  level. 
Work  packages  must  be  distinguishable 
from  each  other  and  must  include  definite 
start  and  completion  dates.  They  are  pre¬ 
pared  by  the  contractor  with  government 
concurrence. 

3.4  SCHEDULE  PREPARATION 

As  stated  earlier,  scheduling  is  a  critical 
element  of  the  plaiming  process.  Con¬ 
versely,  plaiming  is  critical  to  the  devel¬ 
opment  of  effective  schedules.  Near-term 
scheduling  can  and  should  be  accom¬ 
plished  in  sufficient  detail  to  support 
management  at  each  level.  Far-term,  or 
rolling-wave,  scheduling  will  be  less  pre¬ 
cise,  accounting  for  the  alternative  paths 
that  the  program  may  take.  As  the  pro¬ 
gram  approaches  each  phase,  the  sched¬ 
ule  for  that  phase  will  be  fleshed  out  with 


more  detailed  schedule  information.  The 
schedule  for  the  out-year  phases  will  be 
adjusted  based  on  the  most  current  infor¬ 
mation.  However,  this  should  not  be  taken 
as  a  license  to  make  easy  changes  in  the 
schedule.  Every  effort  should  be  made  to 
maintain  the  original  schedule. 

In  all  programs,  there  will  always  be  a 
requirement  to  make  tradeoffs  between 
cost,  schedule,  and  performance.  Cost  in¬ 
cludes  all  resources — people,  money, 
equipment  and  facilities.  Performance  in¬ 
cludes  quality  and  supportability  param¬ 
eters.  The  best  schedule  supports  the  best 
tradeoff  between  these  competing  de¬ 
mands,  taking  into  account  the  risks  that 
are  associated  with  each  tradeoff  and  the 
impact  on  the  overall  program. 

The  preparation  of  program  schedules 
should  be  done  within  a  formal  structure. 
The  procedures  to  be  followed  should  be 
specified,  to  include  such  things  as  soft¬ 
ware  applications  to  be  used,  the  formats 
for  displays,  and  the  type  of  symbols  to  be 
used.  Also,  clear  lines  of  authority  and 
responsibility  should  be  established.  The 
remainder  of  this  section  discusses  the  logi¬ 
cal  steps  that  should  be  followed  in  pre¬ 
paring  schedules,  to  include  sources  of 
information,  tools  and  techniques,  and  the 
outputs  of  the  steps.  These  steps  are  based 
on  those  described  in  the  Program  Man¬ 
agement  Institute's  Guide  to  the  Program 
Management  Body  of  Knowledge}  While  they 
present  a  somewhat  different  approach 
than  the  IMP/IMS  method,  they  have  ge¬ 
neric  applicability  over  the  range  of  plan¬ 
ning  methods. 

3.4.1  Activity  Definition 

This  step  involves  the  identification  and 
definition  of  those  activities  that  must  be 
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accomplished  to  achieve  the  objectives. 
The  WBS  is  a  logical  source  for  such 
descriptions.  If  a  WBS  is  not  available, 
more  plaiming  must  be  done  in  order  to 
identify  project  activities  clearly.  Other 
inputs  to  the  definition  step  are  the  pro¬ 
gram  scope,  historical  information,  pro¬ 
gram  constraints  and  assumptions,  and 
events  required  by  the  Plaiming,  Program¬ 
ming,  and  Budgeting  System  (PPBS),  the 
requirements  generation  system,  and  DoD 
acquisition  management  process. 

Decomposition  and  templates  are  tech¬ 
niques  commonly  used  in  activity  defini¬ 
tion.  Decomposition  involves  the  succes¬ 
sive  breakdown  of  program  elements  into 
smaller,  more  manageable  components, 
which  eventually  describe  the  activities  to 
be  scheduled.  This  technique  is  essen¬ 
tially  the  same  used  in  WBS  development. 
A  template  is  an  activity  list  or  WBS  ele¬ 
ment  from  another  similar  program  that 
can  serve  as  a  model  for  the  current  pro¬ 
gram  and  provide  a  starting  point  for  de¬ 
fining  specific  activities. 

The  primary  output  of  this  step  is  the  activ¬ 
ity  list,  which  should  contain  a  complete 
description  of  each  of  the  activities  neces¬ 
sary  to  complete  the  program.  This  list 
should  be  linked  to  the  WBS,  which  should 
be  reviewed  and  revised /clarified  as  nec¬ 
essary  to  incorporate  changes  resulting 
from  the  activity  definition  process.  Sup¬ 
porting  details  for  each  activity,  such  as 
constraints  and  assumptions,  should  also 
be  developed  and  documented. 

3.4.2  Activity  Sequencing 

This  step  involves  the  accurate  identifica¬ 
tion  of  constraints/  relationships  among  ac¬ 
tivities  and  establishing  the  order  in  which 
the  activities  will  be  accomplished. 


There  are  several  inputs  to  this  step: 

•  The  activity  list  developed  in  the  activ¬ 
ity  definition  step, 

•  The  product  description  and  character¬ 
istics, 

•  Mandatory  constraints/ dependencies, 
such  as  the  fact  that  a  prototype  must  be 
fabricated  before  it  can  be  tested, 

•  Discretionary  constraints/depend¬ 
encies  developed  by  the  program  manage¬ 
ment  team  based  on  "best  practices"  or 
specific  sequences  desired  by  management, 

•  External  dependencies,  such  as  avail¬ 
ability  of  test  sites,  and 

•  Other  constraints  and  assumptions. 

A  number  of  tools  and  techniques  are  use¬ 
ful  in  developing  the  logic  diagrams  that 
reflect  the  desired  activity  sequencing. 
They  include  various  network  scheduling 
techniques  that  are  discussed  in  Chapters  4 
and  6.  In  addition,  a  number  of  scheduling 
software  programs  develop  activity  se¬ 
quencing.  Their  selection  and  use  are  dis¬ 
cussed  in  Chapter  9. 

The  output  of  this  step  is  a  network  dia¬ 
gram  that  reflects  the  sequence  of  activities 
based  on  the  inputs  described  above.  This 
diagram  should  be  augmented  with  a 
narrative  description  of  the  sequencing  ap¬ 
proach  and  a  detailed  discussion  of  any 
unusual  or  complex  sequences.  Activity 
lists  should  be  reviewed  and  revised  to 
reflect  any  changes  necessitated  by  activity 
sequencing. 

3.4.3  Activity  Duration  Estimating 

Activity  duration  estimating  is  the  determi- 
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nation  of  the  time  required  to  complete  the 
activities  that  make  up  the  program.  This 
is  one  of  the  most  difficult  aspects  of  sched¬ 
ule  development  and  should  be  performed 
by  people  who  are  most  familiar  with  the 
activity.  Two  key  inputs  to  the  estimation 
process  are  the  resources  required  and  as¬ 
signed  for  the  activity  and  the  capabilities 
of  the  resources  assigned.  Historical  infor¬ 
mation  from  other  programs  and  from  com¬ 
mercial  databases  can  also  be  helpful  in 
developing  accurate  estimates. 

The  following  techniques  are  commonly 
used  in  estimating  activity  durations: 

•  Expert  judgment  guided  by  historical 
information, 

•  Analogous  estimating  based  on  expe¬ 
rience  of  similar  programs, 

•  Parametric  estimating  based  on  formu¬ 
las  describing  relationships  among  pro¬ 
gram  parameters  and  time,  and 

•  Use  of  simulation  to  develop  distri¬ 
butions  of  probable  duration  of  each 
activity. 

The  output  of  this  step  is  an  estimate  of  the 
likely  amount  of  time  to  complete  each 
activity.  These  estimates  should  also  in¬ 
clude  a  range  of  possible  values,  e.g.,  3 
weeks  ±  1  week,  and  a  clear  statement  of 
the  assumptions  made  in  the  estimation 
process. 

3.4.4  Schedule  Development 

This  step  involves  the  development  of 
realistic  start  and  finish  dates  for  each 
activity.  An  iterative  process,  schedule 
development  takes  into  account  activity 
sequencing,  duration  estimates,  resource 


requirements  and  availability,  calendars 
that  show  when  work  can  be  performed, 
constraints,  assumptions,  and  risk. 

The  output  of  this  step  is  a  set  of  sched¬ 
ules  for  the  program.  These  include  the 
master  program  schedule  and  the  support¬ 
ing  detailed  schedules,  which  should  re¬ 
flect  the  best  balance  possible  between  com¬ 
peting  demands  of  time  and  resources. 
They  should  also  take  into  account  the  risk 
associated  with  time,  cost,  and  performance 
tradeoffs  and  the  impact  on  the  overall 
program. 

A  number  of  techniques  and  tools  are  useful 
in  developing  schedules,  many  of  which  are 
contained  in  various  scheduling  software 
applications.  Many  of  these  applications 
contain  the  capability  to  perform  various 
types  of  mathematical  analyses  to  calculate 
theoretical  start  and  finish  dates  for  each 
activity  based  on  the  overall  sequencing  of 
the  program  activities.  Two  of  the  more 
commonly  known  analysis  techniques  are 
critical  path  method  (CPM)  and  the  Pro¬ 
gram  Evaluation  and  Review  Technique 
(PERT).  They  are  discussed  in  greater 
detail  in  Chapter  6. 

Other  scheduling  development  techniques 
that  are  commonly  used  focus  on  schedule 
development  in  light  of  resource  (time, 
people,  funds,  material)  constraints.  These 
techniques  provide  the  means  to  manage  the 
affect  of  these  constraints  through  the  com¬ 
pression  of  activity  duration  and  the  leveling 
of  resources  throughout  activities.  Schedule 
compression  and  resource  leveling  are  dis¬ 
cussed  in  more  detail  in  Chapter  6. 

3.4.5  Schedule  Control 

The  final  step  in  the  schedule  preparation 
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process  is  to  identify  schedule  variations  and 
to  manage  actual  changes  to  the  developed 
schedules.  A  schedule  change  control  sys¬ 
tem  that  defines  the  procedures  by  which 
changes  canbe  made  should  be  established 
and  integrated  into  the  program's  overall 
change  control  system.  The  schedule 
change  control  system  should  address  such 
things  as  the  methods  of  schedule  perfor¬ 
mance  tracking  and  the  approval  process 
for  authorizing  changes.  The  need  for  sched¬ 
ule  changes  can  be  caused  by  a  number  of 
factors,  to  include: 

•  Failure  to  achieve  planned  dates  for 
specific  activities  or  events, 

•  Internal  program  management  assess¬ 
ment  and  replanning,  and 

•  External  direction,  such  as  reallocation 
of  funding. 

When  evaluating  these  factors,  it  is  im¬ 
portant  to  determine  what,  if  any,  sched¬ 
ule  change  is  necessary.  For  example,  if 
an  activity  that  is  not  on  the  critical  path  is 
not  completed  as  planned,  it  may  not  have 
any  effect  on  the  overall  program  sched¬ 
ule.  Consequently,  it  may  not  require  any 
significant  schedule  change. 

The  schedule  change  control  system 
should  also  include  procedures  for  imple¬ 
menting  schedule  changes.  Such  proce¬ 
dures  should  address  the  requirement  to 
keep  all  program  stakeholders,  especially 
the  users,  advised  of  any  significant  sched¬ 
ule  changes.  They  should  also  address  the 
process  for  adjusting  the  schedule  baseline 
and  the  overall  program  plan  when  neces¬ 
sary  schedule  changes  are  severe.  The 
change  control  system  can  also  serve  as  a 
good  database  of  lessons  learned.  Conse¬ 
quently,  information  concerning  sched¬ 


ule  variations,  their  evaluation,  and  the 
development  of  corrective  actions  should 
be  documented  and  made  readily  avail¬ 
able  to  members  of  the  program's  man¬ 
agement  team,  and  to  other  programs. 

3.5  SCHEDULE  RISK 

In  Chapter  2,  we  discussed  the  relation¬ 
ship  between  risk  management  and  pro¬ 
gram  scheduling.  In  this  section,  we  dis¬ 
cuss  the  risk  associated  with  the  program 
schedule.  Uncertainty  exists  in  every 
schedule.  It  is  impossible  to  predict,  with 
complete  confidence,  the  length  of  time 
necessary  to  complete  an  activity,  meet  a 
milestone,  or  deliver  a  system.  Little  in¬ 
formation  exists  in  the  early  phases  of  a 
program,  and  plaimers  must  rely  on  per¬ 
sonal  experience  and  the  estimates  of  ex¬ 
perts.  As  a  program  progresses  through 
the  acquisition  cycle,  more  information 
becomes  available.  Schedules  developed 
in  the  latter  phases  of  a  program  are  based 
on  more  information  and  analyses,  but 
they  still  lack  complete  certainty.  Uncer¬ 
tainty  introduces  the  element  of  risk  in  the 
planning  process.  Schedule  risk  is  the 
likelihood  of  failing  to  meet  schedule  plans 
and  the  effect  of  that  failure. 

When  creating  a  schedule,  or  when  deter¬ 
mining  overall  program  risk,  the  PM  must 
assess  the  risk  associated  with  the  sched¬ 
ule.  One  technique  for  assessing  this  sched¬ 
ule  risk  involves  estimate  contributions 
for  each  activity's  duration  and  aggregat¬ 
ing  these  distributions  using  a  Monte  Carlo 
simulation  or  other  analytical  tools.  The 
resulting  program-level  schedule  is  then 
analyzed  to  determine  the  actual  sched¬ 
ule  risk  and  to  identify  the  schedule  risk 
drivers. 

This  technique  uses  a  range  of  times  that  it 
will  take  to  complete  each  activity  instead 
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of  single-point  estimates.  This  approach 
results  in  a  more  realistic  estimate  of  sched¬ 
ule  risk  because  it  accounts  for  much  of  the 
uncertainty  inherent  in  the  use  of  single- 
point  estimates.  Their  use  invariably  leads 
to  underestimating  the  time  required  to 
complete  the  program  and,  therefore, 
schedule  overruns,  primarily  because  the 
point  estimates  do  not  adequately  address 
the  uncertainty  inherent  in  the  individual 
activities. 

This  range  of  values  for  each  activity  de¬ 
fines  a  probability  distribution  for  the  du¬ 
ration  of  the  activity.  These  distributions 
are  then  combined  to  determine  the  pro¬ 
gram-level  schedule  estimate.  This  ap¬ 
proach  enables  PMs  to  estimate  early  in  a 
program  if  there  is  a  significant  likelihood 
of  overruiming  the  program  schedule  and 
by  how  much.  It  also  identifies  program 
activities  that  are  on  the  "highest  risk  path. " 

This  technique  can  be  used  in  any  acqui¬ 
sition  phase  beginning  with  the  comple¬ 
tion  of  the  first  statement  of  work.  The 
schedule  probability  distribution  function 
for  each  key  activity  should  be  developed 
as  soon  as  the  activity  is  included  in  the 
master  schedule.  The  distribution  func¬ 
tions  should  be  periodically  reviewed  and 
revised,  if  necessary,  at  least  once  per  phase. 

The  technique  should  be  applied  by  a  small 
government-industry  team  consisting  of 
schedule  analysts  and  technical  experts 
who  understand  the  significance  of  previ¬ 
ous  risk  performance  assessments.  See  the 
DSMC  Risk  Management  Guidebook^  or  the 
Defense  Acquisition  Deskbook,  Section2.5.2.4'^ 
for  more  details  on  the  application  of  this 
technique. 

3.6  SUMMARY 

Scheduling  is  critical  to  the  successful  exe¬ 
cution  of  the  planning  and  controlling 
functions  of  program  management.  In  the 
planning  phase,  it  contributes  to  the 
development  of  detailed  functional  plans 


and  budgets  and  to  identification  and  allo¬ 
cation  of  required  resources  throughout 
program  activities.  During  this  phase  is 
developed  a  set  of  integrated  multi-lay¬ 
ered  schedules  that  tie  together  all  pro¬ 
gram  activities,  showing  their  logical  rela¬ 
tionships  and  any  constraints.  The  level  of 
detail  developed  for  these  schedules  de¬ 
pends  on  program  scope  and  risk.  This 
process  provides  a  hierarchy  of  functional 
and  layered  schedules  that  can  be  useful  in 
monitoring  and  controlling  program 
progress. 

Effective  program  control  depends  on  some 
form  of  integrated  cost,  schedule,  and  tech¬ 
nical  performance  management,  such  as 
the  earned  value  management  system 
(EVMS).  Effective  scheduling  is  key  to  the 
success  of  this  technique.  EVMS  criteria  do 
not  dictate  the  use  of  specific  scheduling 
techniques.  However,  they  do  seek  for¬ 
mality,  consistency,  and  discipline 
throughout  the  scheduling  process. 

A  five-step  process  for  schedule  prepara¬ 
tion  that  is  commonly  used  in  program/ 
project  management  includes: 

•  Activity  definition, 

•  Activity  sequencing, 

•  Activity  duration  estimation, 

•  Schedule  development,  and 

•  Schedule  control. 

Risk  is  inherent  in  all  programs,  and  sched¬ 
uling  is  one  element  of  risk.  Uncertainty 
introduced  in  estimating  the  duration  of 
each  activity  causes  most  schedule  risk. 
PMs  must  assess  the  likelihood  of  failing 
to  meet  schedule  plans  and  the  impact  of 
that  failure.  Probabilistic  techniques  have 
proven  to  be  very  useful  in  conducting 
these  assessments. 
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PROGRAM  STRUCTURE/SCHEDULE  (EXAMPLE) 
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Figure  3-3.  Program  Schedule/Structure  (Example) 
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4 

SCHEDULE  TYPES  AND  THEIR  EVOLUTION 


4.1  INTRODUCTION 

Previous  chapters  of  this  guide  stress  the 
point  that  scheduling  is  an  intrinsic,  indis¬ 
pensable  part  of  program  management  and 
a  key  output  of  the  plaiming  function  of 
that  process.  They  also  describe  the  rela¬ 
tionship  between  the  program  Work  Break¬ 
down  Structure  and  scheduling,  and  intro¬ 
duce  the  concepts  of  the  Integrated  Master 
Plan  and  the  Integrated  Master  Schedule. 
Properly  prepared  and  accurate  schedules 
are  invaluable  tools  in  the  overall  manage¬ 
ment  of  programs.  They  provide  a  road 
map  of  where  the  project  is  going,  the 
resources  required  to  accomplish  the  vari¬ 
ous  project  tasks,  a  means  to  determine 
progress,  and  an  effective  way  to  present 
status  information.  This  chapter  contains 
information  on  the  various  types  of  sched¬ 
ules  generally  in  use  today,  their  character¬ 
istics,  advantages  and  disadvantages,  and 
how  they  have  evolved.  Subsequent  chap¬ 
ters  provide  more  detailed  information  on 
each  of  the  schedule  types,  along  with  in¬ 
formation  on  the  selection  and  use  of 
scheduling  software. 

4.2  SCHEDULE  TYPES 

Schedules  can  be  presented  in  a  variety  of 
ways.  Regardless  of  how  they  are  dis¬ 
played,  schedules  essentially  convey  in¬ 
formation  concerning  one  (or  a  combina¬ 
tion)  of  the  following  categories: 

•  Activities  or  tasks  to  be  accomplished 
over  a  period  of  time,  and 


•  Events  or  milestones,  that  take  place  at 
a  point  in  time,  such  as  a  Defense  Acquisi¬ 
tion  Board  (DAB)  milestone  review. 

Dependencies  or  constraints  among  activi¬ 
ties  or  events.^ 

Currently,  four  types  of  schedules  are  in 
common  use  and  depict  the  categories  of 
information  described  above.  They  are  the 
Gantt  or  bar  chart,  the  milestone  schedule  / 
chart,  the  network  schedule,  and  the  pro¬ 
duction  schedule.  The  evolution,  character¬ 
istics,  and  uses  of  each  of  these  schedules 
are  described  in  the  following  paragraphs, 
and  a  more  detailed  treatment  of  each  of 
them  is  contained  in  subsequent  chapters. 

4.2.1  Gantt  and  Milestone  Charts 

Gantt  charts  and  milestone  charts  are  nor¬ 
mally  combined  to  show  a  program's 
schedule;  therefore,  they  are  discussed  in 
this  context.  The  Gantt  chart  is  used  to 
provide  information  concerning  activities. 
It  is  commonly  referred  to  as  a  bar  chart, 
since  it  depicts  an  activity  as  a  horizontal 
bar  imposed  over  a  time-line,  or  calendar. 
It  shows  the  plaimed  start  and  finish  dates 
for  the  activity  and  may  provide  informa¬ 
tion  about  task  progress,  including  sched¬ 
ule  slips  or  gains.  Figure  4-1  is  an  example 
of  a  simple  Gantt  chart  that  shows  the 
planned  schedule  for  four  activities. 
Progress  in  accomplishing  each  activity 
can  be  shown  on  each  of  the  bars,  as  shown 
by  the  shaded  portions  of  activities  1  and  2. 


19 


The  Gantt  chart  was  the  first  formal  sched¬ 
uling  technique  developed.  It  dates  back 
to  the  early  20*  century  when  Henry  L. 
Gantt  first  introduced  it  while  working  at 
the  Frankford  Arsenal  during  World  War 
1.  It  was  developed  to  provide  a  more 
formal  and  systematic  way  to  schedule 
tasks  when  time  was  an  imprtant  factor. 

The  Gantt  chart  has  survived  in  its  basic 
form  to  this  day  and  continues  to  be 
widely  used  as  a  scheduling  tool  at  all 
levels  within  organizations.  Its  value 
lies  in  its  simplicity  and  its  ability  to 
convey  considerable  information  in  a 
clear  and  concise  manner.  In  the  past,  the 
principal  shortcoming  of  the  traditional 
Gantt  chart  was  its  inability  to  clearly 
depict  dependencies  or  constraints 
among  activities,  making  it  difficult  to 
analyze  schedules  and  optimize  the  allo¬ 
cation  of  resources  to  the  activities.  Some 
scheduling  software  programs  now  make 
it  possible  to  show  relationships,  thereby 


improving  its  utility.  The  Gantt  chart  is 
very  useful  in  reporting  project  status  and 
in  managing  individual  activities  or  simple 
projects  with  few  tasks. 

Subsequent  to  the  development  of  the  Gantt 
chart,  plarmers  and  managers  used  a  simi¬ 
lar  approach  to  depict  information  about 
significant  project  events,  focusing  on  spe¬ 
cific  points  in  time.  These  events  repre¬ 
sented  project  milestones — hence  the  in¬ 
troduction  of  the  milestone  chart.  The  mile¬ 
stone  chart  shows  when  an  event  is  sched¬ 
uled  and  when  it  is  actually  accomplished. 
Figure  4-2  is  an  example  of  a  milestone 
chart  showing  the  status  of  four  events; 
each  of  these  events  represents  the  comple¬ 
tion  of  the  four  activities  shown  in  the 
example  Gantt  chart  in  Figure  4-1. 

Like  the  Gantt  chart,  the  strength  of  this 
milestone  chart  as  a  scheduling  technique 
lies  in  its  relative  simplicity  and  its  ability 
to  concisely  display  project  information. 


Activity 
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Feb 

Mar 

Apr 

May 

Jun 

Identify  User  Requirements 
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Identify  Performanc 

Identify  Interface  R 

Prepare  SW  Require 

Legend 
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Actuai 

;e  Requirements 

equirements 
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M 

J 
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t: 

V 
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Figure  4-1 .  Gantt  Chart  Example 
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Event 

Jan 

Feb 

Mar 

Apr 

May 

Jun 

User  Requirements  Identified 

Performance  Requirements  Identified 

Interface  Specs  Identified 

SW  Requirements  Spec  Completed 

A 

A 

A 

Legend 

Panned  A 
Actual  A 

Figure  4-2.  Milestone  Chart  Exampie 


especially  at  the  "big  picture"  level.  How¬ 
ever,  it  does  have  shortcomings  that  limit 
its  effectiveness  in  day-to-day  project  man¬ 
agement.  As  shown  in  Figure  4-2,  the  mile¬ 
stone  chart  can  depict  the  events  corre¬ 
sponding  to  the  completion  of  an  activity. 

However,  it  does  not  reflect  the  progress  in 
accomplishing  the  activity.  In  this  case,  a 
manager  relying  on  this  milestone  chart 
information  could  be  surprised  if  the 
planned  completion  date  is  not  achieved. 
With  no  warning  or  indicators  of  schedule 
slippage,  the  manager  loses  any  flexibility 
in  attacking  the  underlying  problems  caus¬ 
ing  the  slippage.  This  shortcoming  can  be 
compensated  for  by  the  addition  of  interme¬ 
diate  events  or  through  the  use  of  combined 
Gantt  and  milestone  charts.  This  is  discussed 
in  more  detail  in  the  next  chapter. 

Another  weakness  of  the  milestone  chart  is 
the  difficulty  to  clearly  visualize  the 
relationships,  dependencies,  and  con¬ 
straints  among  the  various  project/pro- 
gram  activities  and  events.  In  spite  of  these 
shortcomings,  the  milestone  chart  can  be 
an  effective  way  of  presenting  the  project 
or  program  status  at  higher  levels  of  man¬ 
agement  review. 


Perhaps  the  biggest  shortfall  of  the  Gantt 
and  milestone  charts  is  that  neither  of 
them,  nor  the  combination  of  both,  allow 
detailed  schedule  analysis.  However, 
every  PM  must  know  and  understand 
Gantt  and  milestone  charts  for  two  simple 
reasons:  everybody  uses  them,  and  nor¬ 
mally,  one  of  the  first  steps  in  the  planning 
process  is  to  construct  a  schedule  using  a 
Gantt  chart. 

4.2.2  Network  Schedules 

Network  scheduling  was  developed  to 
overcome  the  primary  shortcoming  of  the 
Gantt  and  milestone  charts — the  inability 
to  clearly  portray  the  relationships,  depen¬ 
dencies,  and  constraints  among  the  project 
activities  and  events.  A  network  schedule 
is  a  graphical  display  of  a  project,  includ¬ 
ing  a  representation  of  these  relationships. 
Figure  4-3  shows  an  example  of  a  network 
schedule  for  a  simple  project. 

In  this  example,  the  lines  represent  project 
activities  A  through  H;  the  nodes  repre¬ 
sent  the  events  associated  with  the  begin¬ 
ning  and  end  of  the  activities.  The  net¬ 
work  shows  the  following  constraints 
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among  the  activities:  activity  A  must  be 
completed  before  activities  B,  C,  or  D  can 
begin;  B  must  be  completed  before  E  can 
begin;  F  carmot  begin  until  D  is  completed; 
G  carmot  begin  until  C  and  E  are  done,  and 
H  carmot  begin  until  F  and  G  are  com¬ 
pleted.  In  addition  to  showing  this  type  of 
sequencing  constraints,  network  schedules 
can  also  show  the  time  and  resources 
plarmed  for  each  activity  and  thus  provide 
managers  with  a  mechanism  to  monitor 
and  control  the  project.  A  later  chapter 
covers  network  schedules  in  detail. 

The  advent  of  network  schedules  can  be 
traced  back  to  the  1920s  and  the  evolu¬ 
tion  of  operations  research.  Analysts  re¬ 
alized  the  inability  to  depict  dependen¬ 
cies  and  constraints  was  a  major  short¬ 
coming  of  existing  scheduling  techniques, 
and  attempted  to  solve  the  problem 
through  the  application  of  network  theory. 
The  translation  of  this  theory  into  a  usable 
scheduling  tool  was  hindered  by  the  in¬ 
ability  to  process  network-related  data 
in  a  timely  fashion.  The  development  of 
the  computer  provided  the  means  to  au¬ 
tomate  this  data  processing  and,  by  the 
1950s,  the  concept  of  network  scheduling 


was  being  applied  to  large,  complex  pro¬ 
grams.  The  first  major  network  schedul¬ 
ing  technique  developed  was  the  Pro¬ 
gram  Evaluation  and  Review  Technique, 
or  PERT,  which  was  used  as  a  manage¬ 
ment  tool  for  scheduling  and  controlling 
the  Navy's  Polaris  missile  program.  PERT 
enables  managers  to  visualize  the  entire 
program,  see  interrelationships  and  de¬ 
pendencies,  and  recognize  when  and 
where  delays  are  acceptable.  One  of  the 
key  features  of  PERT  is  the  use  of  prob¬ 
ability  techniques  to  develop  a  set  of 
time  estimates  for  each  program  activity, 
making  it  particularly  well-suited  for  pro¬ 
grams  where  it  is  difficult  to  make  accu¬ 
rate  estimates  with  high  confidence.  Gon- 
current  with  the  development  of  PERT, 
the  construction  industry  developed  a 
network  scheduling  system  based  on  the 
concept  of  critical  path.  A  project's  criti¬ 
cal  path  is  the  most  time-consuming  route 
through  the  network  activities  that  must 
be  completed  in  order  to  finish  the  project. 
This  approach,  named  Gritical  Path  Method 
(GPM),  was  designed  to  focus  on  perfor¬ 
mance  time  and  total  program  cost.  Some 
publications  refer  to  GPM  as  the  Arrow 
Diagram  Method  (ADM). 
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PERT  and  CPM  scheduling  techniques  have 
many  similarities.  For  example,  each  shows 
the  relationships  among  activities  and 
events,  both  include  the  project's  critical 
path,  and  the  structure  of  each  allows  analy¬ 
sis  of  the  tasks  to  be  done,  resources  as¬ 
signed  to  do  them,  and  the  time  associated 
with  each  task.  Both  techniques  use  nodes 
to  represent  events  (beginning  and  end  of 
activities)  and  lines  to  represent  the  activi¬ 
ties. 

A  third  network  scheduling  technique  is  the 
Precedence  Diagram  Method  (PDM),  which 
was  developed  subsequent  to  the  PERT/ 
CPM  techniques.  Its  function  is  to  permit  a 
more  accurate  depiction  of  relationships 
among  various  activities  than  is  possible 
using  the  other  two  techniques.  PERT/ 
CPM  techniques  are  essentially  limited  to 
"finish-start"  relationships  (i.e.,  activity  B 
cannot  start  until  activity  A  is  completed). 
The  PDM  technique  can  depict  other  rela¬ 
tionships  that  permit  a  more  accurate  and 
realistic  portrayal  of  the  program's  activi¬ 
ties,  such  as  "start-start"  (i.e.,  activity  B  can¬ 
not  start  until  activity  A  starts).  The  tech¬ 
nique  accomplishes  this  through  the  use  of 
nodes  to  depict  activities  and  lines  to  depict 
relationships.  These  three  techniques  are 
discussed  in  greater  detail  in  Chapter  6. 
Network  scheduling  techniques  provide 
managers  with  a  powerful  tool  for  schedul¬ 
ing  and  controlling  their  programs/ projects. 
In  general,  they  permit  the  graphic  por¬ 
trayal  of  project  activities  and  relationships 
among  the  activities.  This  provides  the 
basis  for  determining  the  project's  critical 
path,  predicting  shortages,  and  identifying 
possible  reallocation  of  resources  to  solve 
problems.  Through  the  use  of  readily  avail¬ 
able  software,  network  schedules  are  fairly 
easy  to  update  and  rework,  thus  providing 
managers  with  current  program  /  proj  ect  sta¬ 
tus  information  and  control  over  activities 
and  schedules. 


In  spite  of  the  strengths  of  network  schedul¬ 
ing  techniques,  there  are  some  limitations. 
The  value  of  network  schedules  is  directly 
dependent  on  the  validity  of  the  time  esti¬ 
mates  for  each  activity.  In  addition,  it  is 
sometimes  difficult  to  accurately  portray 
all  activities  and  relationships,  especially 
for  very  large,  complex  programs.  Thus, 
considerable  "up  front"  work  is  required 
to  develop  an  effective  network  schedule. 
Detailed  networks,  once  developed,  tend 
to  be  the  focus  of  management  attention 
when,  in  fact,  there  will  undoubtedly  be 
other  factors  not  on  the  display  that  will 
require  management  attention. 

4.2.3  Production  Schedules 

Production  scheduling  involves  the  plan¬ 
ning,  execution,  and  control  of  repetitive 
activities,  such  as  the  manufacture  of  a 
large  number  of  identical  items.  Efficient 
production  requires  the  proper  balance  of 
materials,  facilities,  and  persoimel  skills. 
It  also  requires  a  means  to  monitor  the 
production  process. 

The  Line  of  Balance  (LOB)  technique,  while 
not  truly  a  scheduling  tool,  is  such  a  moni¬ 
toring  technique  that  can  provide  early 
warning  of  potential  problems  that  can 
affect  program  schedule.  It  is  especially 
useful  for  monitoring  repetitive  processes 
where  it  is  essential  to  balance  inventory 
acquisition  with  the  production  process 
and  delivery  requirements.  The  LOB  tech¬ 
nique  consists  of  four  elements:  (1)  objec¬ 
tives  of  the  program,  i.e.,  contract  sched¬ 
ule  and  actual  deliveries;  (2)  production 
plan;  (3)  current  program  status  or  inven¬ 
tory;  and  (4)  a  comparison  between  where 
the  program  is  and  where  it's  supposed  to 
be,  (that  is,  program  inventories  versus 
the  LOB).  These  elements  are  discussed 
in  more  detail  in  Chapter  7. 
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The  origin  of  LOB  is  not  clear,  but  it  is 
believed  it  was  developed  to  help  manage 
defense-related  contracts  in  the  1940s  and 
50s.  It  is  still  used  today  in  both  defense  and 
commercial  industry.  While  government 
PMs  or  their  staffs  will  probably  not  need  to 
directly  develop  or  apply  the  LOB  tech¬ 
nique,  they  should  understand  it  and  real¬ 
ize  that  it  can  be  a  valuable  tool  for  contrac¬ 
tors  to  monitor  the  status  of  production 
contracts  and  to  present  status  information. 

This  technique  can  point  out  problems  be¬ 
fore  their  impact  on  finished  product  deliv¬ 
eries  shows  up,  thereby  allowing  managers 
to  make  corrections.  It  also  allows  manag¬ 
ers  to  see,  in  the  middle  of  a  contract,  whether 
they  can  meet  the  contract  schedule  if  they 
continue  working  as  they  have  been.  An¬ 
other  advantage  of  LOB  is  that  it  focuses 
attention  on  the  production  activities  where 
there  are  problems,  thereby  facilitating  ini¬ 
tiation  of  corrective  action. 

There  are  some  limitations  with  the  LOB 
technique.  First,  it  is  best  suited  for  produc¬ 
tion  and/ or  assembly-type  processes  that 
are  stable.  The  activities  that  make  up  the 
production  plan  must  be  definable  and  well 
understood.  Second,  while  this  technique 
pinpoints  where  a  problem  exists,  it  cannot 
identify  the  specific  problem. 

4.3  SUMMARY 

Each  scheduling  method  has  strengths  and 
limitations.  Program  Mangers  must  be  fa¬ 
miliar  with  all  of  the  techniques  and  choose 


the  method  that  allows  them  to  meet  their 
goals.  The  choice  of  schedule  type  depends 
on  a  number  of  factors,  such  as,  the  purpose 
of  the  schedule,  its  intended  use,  and  the 
decisions  to  be  made  from  the  information 
presented.  For  example,  day-to-day  man¬ 
agement  of  a  project  consisting  of  a  number 
of  related  and  complex  activities  may  re¬ 
quire  a  schedule  that  depicts  the  tasks,  their 
planned  duration,  dependencies,  progress, 
and  resources  allocated  to  each  of  them.  If  a 
PM  must  do  detailed  schedule  analysis  of 
this  type  of  project,  then  the  PM  will  most 
likely  use  a  network  schedule.  This  method 
is  the  only  way  to  use  probability  distribu¬ 
tions  for  time  estimates  rather  than  complet¬ 
ing  an  activity  and  project  in  a  certain  time. 

On  the  other  hand,  the  management  of  a 
single  activity  may  require  a  schedule  that 
reflects  only  the  time  planned  for  accom¬ 
plishing  the  task  and  the  current  status. 
Schedules  showing  only  events,  such  as  the 
completion  dates  of  planned  activities,  or 
bar  charts  may  be  sufficient  in  those  cases 
when  the  audience  may  not  be  concerned 
with  the  details  of  the  activities. 

As  a  rule  of  thumb,  Gantt  and  milestone 
charts  are  useful  to  present  information  and 
summarize  program  activities.  They  are 
also  usually  the  starting  points  for  detailed 
planning  and  creating  a  network  schedule. 
Network  schedules  are  usually  created  for 
detailed  planning  and  analyses.  They  are 
necessary  to  determine  the  feasibility  of 
meeting  program  goals,  assessing  risk,  and 
conducting  sensitivity  analyses. 


_ ENDNOTES _ 
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5 

GANTT  AND  MILESTONE  CHARTS 


5.1  DESCRIPTION 

As  discussed  in  Chapter  4,  the  Gantt  chart 
is  one  of  the  oldest  planning  tools  in 
existence  and  is  still  used  today  at  all 
levels  of  project  management.  For  ex¬ 
ample,  PMs  use  Gantt  charts  to  report 
information  concerning  program  activi¬ 
ties  at  milestone  decision  briefs,  while 
engineers  may  use  them  to  manage  the 
tasks  associated  with  design  activities. 
Because  PMs  often  use  Gantt  and  mile¬ 
stone  charts  to  report  information  to  re¬ 
view  groups,  they  are  treated  jointly  in 
this  chapter. 

In  its  simplest  form,  a  Gantt  chart  is  a 
schedule  that  shows  the  start/ stop  dates 
of  a  program's  individual  activities.  It 
uses  symbols  superimposed  on  a  calen¬ 
dar  to  provide  information  about  the 
original  plan,  the  status  of  the  activity, 
and  any  forecasted  changes  to  the  plan. 


There  is  no  standard  set  of  Gantt  chart  sym¬ 
bols.  Planners  should  define  them  and  con¬ 
sistently  use  them  throughout  the  chart.  Fig¬ 
ure  5-1  shows  an  example  of  the  symbols  that 
could  be  used  in  Gantt  charts. 

The  schedule  is  displayed  as  a  series  of 
horizontal  bars  representing  the  duration  of 
activities.  A  manager  may  show  actual 
progress  against  the  schedule  by  shading  in 
each  bar  as  activity  progresses  or  may  use  a 
colored  bar  that  is  parallel  to  the  schedule 
bar.  Figure  5-2  shows  a  simple  Gantt  chart 
that  illustrates  activities  involved  in  devel¬ 
oping  components  of  a  weapons  system. 
This  type  of  display  can  be  useful  for  convey¬ 
ing  information  about  the  program  to  those 
involved  in  its  review  or  those  charged  with 
its  day-to-day  management. 

From  this  example,  we  can  see  that  as  of  late 
March,  the  design,  fabrication,  and  assembly 
of  the  payload  are  ahead  of  schedule,  [A]. 


Symbol 

Meaning 

A _ V 

Planned  activity  schedule 

Status  of  activity 

Forecasted  completion  behind  schedule 

Forecasted  completion  ahead  of  schedule 

A  V~T 

A  TV 

Figure  5-1 .  Example  Gantt  Chart  Symbols 
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Figure  5-2.  Example  Gantt  Chart 


Based  on  this  information,  and  an  analysis  guidance  and  control  subsystem  is  not  go¬ 
of  the  activities,  the  PM  has  revised  the  ing  as  well  as  plaimed.  As  of  late-March, 

plaimed  completion  date  for  the  payload  the  fabrication  is  well  behind  schedule, 

fabrication,  [B],  In  analyzing  the  current  [D],  After  reviewing  the  progress  and  re¬ 
status,  the  PM  has  determined  that  much  of  maining  work,  the  PM  has  slipped  the 

the  work  in  payload  assembly  will  have  to  plaimed  completion  dates  for  the  fabrica- 

be  done  toward  the  end  of  the  planned  tion  and  assembly  activities,  [E],  They  be¬ 
ach  vity  period.  (In  other  words,  the  work  is  lieve  that  it  is  too  early  to  revise  the  planned 

not  uniformly  distributed  throughout  the  completion  dates  for  test  and  rework,  and 

period.)  Thus,  even  though  this  activity  is  the  system  integration  and  test  activities, 

ahead  of  schedule  now,  the  PM  has  de-  However,  the  slippage  already  experienced 

cided  not  to  revise  the  planned  completion  should  serve  as  a  warning  that  this  entire 

date  for  assembly  and  test,  [C].  This  Gantt  development  effort  may  be  in  trouble  and 

chart  also  shows  that  development  of  the  will  require  close  monitoring. 
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While  the  Gantt  chart  focuses  on  activities 
and  their  duration,  the  milestone  chart  fo¬ 
cuses  on  planned  significant  events  sched¬ 
uled  to  occur  at  specific  times  in  the  pro¬ 
gram.  Such  events  could  be  the  initiation 
or  completion  of  a  particularly  important 
or  critical  activity,  equipment  deliveries, 
reviews,  or  approval  dates.  Like  the  Gantt 
chart,  the  milestone  chart  uses  symbols 
imposed  on  a  calendar  to  provide  informa¬ 
tion  about  planned  and  actual  completion 
dates  and  any  revisions  to  the  milestone 
schedule.  There  is  no  standard  set  of  sym¬ 
bols  for  milestone  charts.  Figure  5-3  shows 
the  symbols  prescribed  for  reporting  mile¬ 
stone  information  within  the  Air  Force 
Material  Gommand.  Different  scheduling 
software  will  often  use  unique  symbols. 


The  important  thing  is  that  the  symbols  be 
clearly  defined  and  consistently  applied. 

Figure  5-4  shows  an  example  milestone 
chart  for  the  program  described  in  the  Gantt 
chart  in  Figure  5-2.  Note  that  events  dis¬ 
played  correspond  to  the  beginning  of 
some  activities  and  the  completion  of  all  of 
them.  Other  events  displayed  represent 
important  occurrences  and  key  decision 
points  within  each  of  the  activities,  e.g., 
preliminary  and  critical  design  reviews, 
"make  or  buy"  decision,  etc.  In  this  ex¬ 
ample,  we  see  that  as  of  late-March  pay- 
load  design  has  progressed  on  schedule, 
[A],  and  that  plaimed  completion  date  for 
fabrication  has  been  revised  ahead  of  the 
original  schedule,  [B].  As  discussed  in  the 


Standard  symbols  have  been  adapted  for  Air  Force  milestone 
schedules.  The  most  common  symbols  used  and  their  meanings  are 
shown  below. 

Basic  Symbol 

Meaning 

0 

Schedule  Completion 

1 

Actual  Completion 

0 

Previous  Scheduled  Completion — Still  in  Future 

♦ 

Previous  Scheduled  Completion — Date  Passed 

Representative  Uses 

Meaning 

Anticipated  Slip — Rescheduled  Completion 

♦  0 

Actual  Slip — Rescheduled  Completion 

1  i 

Actual  Slip — Actual  Completion 

J. 

Actual  Completion  Ahead  of  Schedule 

*  0 

Time  Span  Action 

0  ^ 

Continuous  Action 

Figure  5-3.  Example  Milestone  Chart  Symbols 
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J 

F 

M 

A 

M 

J 

J 

A 

S 

0 

N 

D 

Payload  Design 

Begin  Payload  Design 

Payload  Preliminary  Design  Review  (PDR) 
Payload  Critical  Design  Review  (CDR) 

Complete  Payload  Design 

Payload  Fabrication 

Make  or  Buy  Decision 

Tooling  Complete 

Fabrication  Complete 

Assemble  Payload 

Begin  Assembly 

Delivery  of  Parts  Complete 

Assembly  Complete 

Payload  Test  &  Rework 

Test  Plan  Complete 

Test  Readiness  Review 

Test  &  Rework  Complete 

Guidance  &  Control  Design 

Begin  G&C  Design  i 

G&C  PDR 

G&C  CDR 

Complete  G&C  Design 

Fabricate  G&C 

Make  or  Buy  Decision 

Tooling  Complete 

Fabrication  Complete 

Assemble  G&C 

Begin  Assembly 

Delivery  of  Parts  Complete 

Assembly  Complete 

Test  and  Rework 

Test  Plan  Complete 

Test  Readiness  Review 

Test  &  Rework  Complete 

Integrate  Payload  and  G&C 

Begin  Integration 

Complete  Integration 

Test  &  Rework 

Test  Plan  Complete 

Test  Readiness  Review 

Test  &  Rework  Complete 

t 

i 

t 

r^] 

i 

k 

t 

\ 

t 

t 

^ o 

[B] 

0 

0 

0 

[D] 

0 

0 

r 

[D] 

0 

[D] 

0 

D 

r 

0 

0 

Now 


Figure  5-4.  Example  Milestone  Chart 
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J 

F 

M 

A 

M 

J 

J 

A 

s 

0 

N 

D 

Payload  Design  ^ 

Payload  Preliminary  Design  Review  (PDR) 
Payload  Critical  Design  Review  (CDR) 
Complete  Payload  Design 

t 

1 

1 

t 

;f> 

1 

Payload  Fabrication 

A _  T 

\/ 

1 

Make  or  Buy  Decision 

Tooling  Complete 

Fabrication  Complete 

t 

0 

Assemble  Payload 

A 

V 

_ 

J 

Delivery  of  Parts  Complete 

Assembly  Complete 

Payload  Test  &  Rework 

A 

y 

T 

J 

Test  Plan  Complete 

Test  Readiness  Review 

Test  &  Rework  Complete 

r 

Guidance  &  Control  Design 

G&C  PDR 

G&C  CDR 

Complete  G&C  Design 

t 

V 

Fabricate  G&C 

A 

y 

i---. 

Make  or  Buy  Decision 

Tooling  Complete 

Fabrication  Complete 

0 

Assemble  G&C 

% 

V 

I 

Delivery  of  Parts  Complete 

Assembly  Complete 

0 

0 

Test  and  Rework 

A 

V 

T 

J 

Test  Plan  Complete 

Test  Readiness  Review 

Test  &  Rework  Complete 

System  Integration  Payload  and  G&C 

A 

I 

I 

Complete  Integration 

System  Test  &  Rework 

A 

I 

I 

Test  Plan  Complete 

Test  Readiness  Review 

Test  &  Rework  Complete 

> 

Figure  5-5.  Example  Combination  Chart 
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Figure  5-6.  Gantt  Chart  with  Ampiifying  Information 


As  discussed  in  the  Gantt  chart  example, 
there  are  problems  in  the  fabrication  of  the 
guidance  and  control  subsystem.  One  of 
the  events  selected  as  a  milestone  was  the 
completion  of  the  tooling  necessary  for 
fabrication.  From  the  example,  we  see  that 
this  event  experienced  an  actual  slip  of 
approximately  one  month,  [C];  this,  in  turn, 
has  caused  the  Program  Manager  to  revise 
the  scheduled  completion  dates  for  fabri¬ 
cation,  parts  delivery,  and  assembly,  [D]. 

Managers  rarely  use  pure  Gantt  or  mile¬ 
stone  charts.  Normally  they  integrate  the 
information  from  these  charts  and  display 
it  in  a  combination  chart.  Such  a  chart  can 
be  useful  in  displaying  the  plaimed  and 
actual  duration  of  activities  using  the  Gantt 
chart  symbols  and  in  monitoring  the 
progress  for  completing  key  events  in  these 
activities  using  the  milestone  symbols.  Fig¬ 
ure  5-5  is  a  combination  chart  showing  the 
activities  and  events  described  in  Figures 
5-2  and  5-4. 

Whereas  the  simple  Gantt,  milestone,  or 
combination  charts  may  be  suitable  for 
reporting  program  status,  most  managers 
need  additional  information  to  plan,  moni¬ 
tor,  and  control  activities.  New  software 
applications  increase  the  utility  of  these 
charts  by  making  it  easy  to  add  informa¬ 
tion,  such  as  budget,  cost,  resources,  etc. 

Today's  programs  use  databases  to  store 
related  schedule  information  and  then  al¬ 
low  users  to  filter,  sort,  and  display  infor¬ 
mation  in  a  variety  of  ways.  They  also 
allow  users  to  tailor  the  software  to  their 
needs  by  adding  customized  information 
to  the  database.  Figure  5-6  shows  how  to 
display  the  relationship  of  one  activity  with 
another  by  drawing  lines  between  related 
activities.  The  Budget  column,  in  which  the 
manager  enters  the  budgeted  cost  for  the 


activity,  is  a  standard  feature  of  the  par¬ 
ticular  program  used  to  create  this  Gantt 
chart.^  The  Assignment,  Cost,  and  Cost/Bud¬ 
get  ratio  columns  are  not  standard  features 
but  were  added  to  the  database  to  demon¬ 
strate  how  the  charts  may  be  customized  to 
meet  individual  needs.  Note  that  the  user 
may  create  computation  fields,  such  as  the 
percentage  and  totals  fields  shown  in  the 
figure. 

5.2  CONSTRUCTING  GANTT  AND 
MILESTONE  CHARTS 

Gantt  and  milestone  charts  are  relatively 
easy  to  construct  when  compared  to  the 
complexity  of  network  charts.  The  first 
step  is  to  decide  the  level  at  which  the 
project  is  to  be  plaimed,  tracked,  and  re¬ 
ported.  This  decision  should  consider  such 
things  as  the  needs  of  the  entire  project 
team,  and  the  degree  of  risk  associated 
with  the  various  program  activities.  Most 
likely  there  will  be  a  need  to  manage  and 
track  at  a  low  level  and  report  at  a  higher 
level.  Gurrent  scheduling  software  has  the 
capability  to  handle  activities  at  various 
program  levels  allowing  insight  and  man¬ 
agement  at  the  lower  levels  and  permitting 
roll  up  of  information  at  higher  levels  for 
reporting  purposes.  To  accomplish  this, 
charts  must  be  developed  in  a  logical  and 
consistent  manner. 

The  next  step  in  constructing  the  charts  is 
the  identification  of  activities  and  mile¬ 
stones  to  be  displayed,  tracked,  and  moni¬ 
tored.  The  WBS  should  be  used  as  the 
primary  source  for  this  identification.  If  a 
WBS  is  not  available,  or  if  it  does  not  go 
down  to  the  necessary  level,  additional 
planning  must  be  done  to  clearly  define 
and  identify  activities  to  be  managed, 
tracked,  and  reported.  Other  sources  for 
identifying  activities  and  events  include 
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the  Acquisition  Strategy,  the  Acquisition 
Program  Baseline,  the  Risk  Management 
Plan,  and  the  Integrated  Management  Plan, 
and  the  Integrated  Management  Plan. 

5.3  GANTT  AND  MILESTONE 
CHART  ADVANTAGES  AND 
DISADVANTAGES 

Gantt  and  milestone  (or  combination)  charts 
provide  a  simple,  effective  means  to 
present  project  information,  and  a  way  to 
monitor  and  control  smaller  projects.  Us¬ 
ing  these  charts  as  scheduling  tools  has 
many  advantages,  but  also  limitations  that 
should  be  understood.  These  pros  and 
cons  are  presented  below.  Evolving  sched¬ 
uling  software  includes  features  that  over¬ 
come  some  of  the  shortcomings  to  varying 
degrees. 

5.3.1  Advantages 

(1)  Simple  to  prepare  and  update, 

(2)  Information  portrayed  in  easily  un¬ 
derstood  format, 

(3)  Relatively  inexpensive  to  prepare 
using  software  tools, 

(4)  Relate  activities  and  calendar  dates, 

(5)  Easy  to  roll  up  information  into 
summary  form, 

(6)  Useful  first  step  for  preparation  of 
more  complex  type  schedules 

(7)  Reliable  estimates  canbe  developed 
when  the  work  is  repetitive  and  when  the 
product  is  easy  to  measure  quantitatively. 


5.3.2  Disadvantages 

(1)  Difficult  to  use  for  detailed  sched¬ 
ule  analysis 

(2)  Do  not  show  the  effects  of  late  or 
early  activity  starts 

(3)  Do  not  represent  dependencies 
among  activities  as  well  as  other  schedul¬ 
ing  methods 

(4)  Do  not  reflect  the  uncertainty  in  the 
plaimed  activity  duration  or  event  date 

(5)  Only  as  reliable  as  the  estimates  on 
which  they  are  based;  looking  at  the  chart 
doesn't  indicate  which  estimates  are  the 
most  reliable 

(6)  Do  not  allow  quick  or  easy  explora¬ 
tion  of  the  consequences  of  alternative  ac¬ 
tions. 

5.4  HOW  AND  WHEN  GANTT  AND 
MILESTONE  CHARTS  ARE 
EMPLOYED 

Gantt  and  milestone  charts  are  best  used 
for  displaying  the  plaimed  activities  and 
events  of  a  project  and  the  progress  in 
meeting  them.  This  makes  them  very  use¬ 
ful  for  presenting  schedule  and  program 
status  information  in  a  concise  simple  for¬ 
mat  at  such  things  as  programor  activity 
reviews. 

Because  of  its  simplicity  and  ease  of  inter¬ 
pretation,  it  is  a  particularly  good  tool  for 
communicating  to  higher  management 
when  information  must  be  presented 
quickly  and  efficiently.  These  charts  may 
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also  be  sufficient  for  management  and  con¬ 
trol  of  simple  projects.  However,  they 
have  limited  utility  for  managing  more 
complex  projects,  since  they  do  not  easily 
capture  interrelationships  among  activi¬ 
ties  and  events  or  reflect  the  uncertainty 
associated  with  time  and  resource  esti¬ 
mates.  Generally,  they  do  not  provide  the 
level  of  information  necessary  for  the  effec¬ 
tive  monitoring  and  control  of  such  pr oj  ects. 


5.5  SUMMARY 

As  scheduling  tools,  Gantt  and  milestone 
charts  provide  a  simple  and  effective  means 
for  displaying  actual  versus  planned 
progress  of  a  program  and  for  showing 
schedule  changes  that  have  occurred.  The 
major  drawback  of  Gaimt  and  milestone 
charts  is  the  limited  degree  fo  detail  and 
dependency  information  they  can  portray. 
However,  recently  developed  software 
scheduling  applications  now  make  it  pos¬ 
sible  to  show  more  of  the  relationships 
among  project  activities  and  events. 
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ENDNOTES 


This  figure  is  an  adaptation  of  sample  charts  from  Fast  Track  Schedule  sample  charts. 
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6 

NETWORK  SCHEDULING 


6.1  DESCRIPTION 

Driven  by  the  increase  in  project  complex¬ 
ity,  managers  developed  the  need  for  better 
schedule  and  control  methods  than  those 
provided  by  Gantt  and  milestone  charts. 
The  shortcomings  of  these  charts  gave  rise  to 
network  scheduling.  Over  time,  different 
applications  of  network  theory  were  devel¬ 
oped  to  address  the  needs  of  managers. 
Today,  essentially  three  networking  tech¬ 
niques  are  in  use:  the  Program  Evaluation 
and  Review  Technique  (PERT);  the  Critical 
Path  Method  (CPM)  [these  two  techniques 
are  also  known  as  Arrow  Diagram  Methods 
(ADM)]  and  the  Precedence  Diagram 
Method  (PDM).  Each  is  discussed  later  in 
this  chapter. 

All  of  these  techniques  provide  the  manager 
with  powerful  tools  to  plan,  analyze,  moni¬ 
tor,  and  control  the  project  and  to  manage 
the  resources  necessary  to  accomplish  project 
tasks.  They  can  help  the  manager  answer 
the  following  questions: 

•  When  is  each  activity  or  task  of  the 
program  scheduled  to  begin  and  end? 

•  Which  activities  must  be  finished  on 
time  to  avoid  missing  the  scheduled  pro¬ 
gram  completion  date? 

•  Can  resources  be  shifted  to  critical 
parts  of  the  program  (those  that  must  be 
completed  on  time)  from  non-critical  parts 
(those  that  can  be  delayed)  without  affect¬ 


ing  the  overall  scheduled  completion  date 
for  the  program? 

•  Among  program  tasks,  where  should 
management  efforts  be  concentrated  at 
any  particular  time? 

Networks  are  a  graphical  portrayal  of  the 
activities  and  events  of  a  project.  They  show 
how  each  activity  relates  to  others  in  the 
project,  the  sequence  of  activities,  and  the 
need  to  perform  some  tasks  before  others. 
Figure  4-3  is  an  example  of  an  ADM  network 
schedule.  Networks  also  facilitate  the  deter¬ 
mination  of  the  impact  of  early  or  late  starts 
or  finishes,  provide  information  about  the 
allocation  of  resources,  and  allow  managers 
to  do  "what  if"  analyses.  With  this  informa¬ 
tion,  managers  may  view  the  status  of  the 
plan,  analyze  progress,  and  evaluate  alter¬ 
natives. 

To  apply  these  networking  techniques,  the 
following  conditions  must  exist: 

•  All  program  activities  must  be  clearly 
defined,  including  identifiable  start  and 
completion  points. 

•  A  logic  diagram  showing  the  sequence 
and  interrelationships  of  activities  must  be 
developed. 

•  The  time  to  complete  each  activity 
must  be  estimated  as  accurately  as  pos¬ 
sible. 
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Accomplishing  these  things  may  require 
considerable  effort  and  the  involvement  of 
people  familiar  with  the  overall  project  and 
those  responsible  for  executing  various 
groups  of  activities.  This  up-front  effort 
provides  an  understanding  of  project  re¬ 
quirements  and  early  identification  of  po¬ 
tential  problem  areas. 

6.1.1  PERT 

In  1958,  the  U.S.  Navy  introduced  the  con¬ 
cept  of  network  scheduling  techniques  by 
developing  PERT  as  a  management  control 
system  for  the  development  of  the  Polaris 
missile  program.  The  focus  of  PERT  was  to 
give  managers  the  means  to  plan  and  con¬ 
trol  processes  and  activities  so  the  project 
could  be  completed  within  the  specified  time 
period.  The  Polaris  program  involved  250 
prime  contractors,  more  than  9,000  subcon¬ 
tractors,  and  hundreds  of  thousands  of  tasks. 

PERT  was  introduced  as  an  event-oriented, 
probabilistic  technique  to  increase  a  PM's 
control  in  projects  where  time  was  the  criti¬ 
cal  factor  and  time  estimates  were  difficult 
to  make  with  confidence.  The  events  used  in 
this  technique  represent  the  start  and  finish 
of  the  activities.  PERT  uses  three  time  esti¬ 
mates  for  each  activity:  optimistic,  pessi¬ 
mistic,  and  most  likely.  From  these  esti¬ 
mates,  an  expected  time  is  calculated  based 
on  a  beta  probability  distribution  for  each 
activity.  The  developers  of  PERT  chose  the 
beta  probability  distribution  because  it  could 
accommodate  nonsymmetrical  situations. 
They  assumed  that  the  probability  of  an 
estimate  being  too  optimistic  would  not  be 
equal  to  the  probability  that  the  same  esti¬ 
mate  would  be  too  pessimistic.  That  is,  if 


estimated  times  could  be  compared  against 
actual  completion  times  in  a  number  of  cases, 
the  variation  would  look  like  the  curve  in 
Figure  6-1. 

The  expected  time,  t  is  the  weighted  aver¬ 
age,  or  mean  time,  for  an  activity  based  on 
the  beta  distribution  and  is  determined  from 
the  following  formula: 

_  a  +  4m  +  b 
^  6 

Using  the  expected  times  and  other  statisti¬ 
cal  properties  of  the  beta  distribution  for 
each  activity,  it  is  possible  to  determine  an 
expected  time  for  completion  of  the  project 
and  the  likelihood  (probability)  that  this  ex¬ 
pected  completion  time  will  be  met.  It  is  also 
possible  to  determine  the  critical  path  for  the 
project — the  most  time-consuming  path 
through  the  network  activities  and  events  to 
project  completion.  Any  delay  on  this  path 
will  delay  the  completion  of  the  project. 

PERT  is  most  useful  when  it  is  difficult  to 
either  accurately  estimate  the  time  required 
for  project  activities  or  to  determine  the  per¬ 
centage  of  work  accomplished  within  an 
activity.  The  percentage  of  work  accom¬ 
plished  can  be  especially  important  when 
analyzing  the  adequacy  of  resources  applied 
to  an  activity.  Projects  best  suited  for  PERT 
are  one-of-a-kind  complex  programs  that 
involve  new  technology  or  processes  and 
research  and  development. 

Fllowing  the  success  of  the  Polaris  program, 
PERT  became  widely  used  throughout  the 
systems  acquisition  community,  to  include 
attempts  to  combine  it  with  cost  data  or 
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Figure  6-1.  Beta  Distribution  with  PERT  Time  Estimates 


other  non-scheduling  aspects  of  program 
management.  As  a  result,  PERT  became  so 
cumbersome  that  the  cost  of  maintaining  it 
far  outweighed  the  benefit.  Consequently, 
the  use  of  PERT  declined  and,  by  the  1970s, 
it  was  only  occasionally  employed  in  de¬ 
fense  system  programs.  Over  the  last  few 
years,  it  has  again  become  relatively  popu¬ 
lar,  particularly  in  the  private  sector.  This 
resurgence  is  due,  in  part,  to  the  develop¬ 
ment  of  PERT  software  or  other  networking 
software  programs  that  can  be  run  on  micro¬ 
computers. 

In  spite  of  misuses  that  have  occurred  in 
PERT  applications,  the  technique  can  be  a 
very  useful  tool  because  it  enables  the  man¬ 
ager  to  visualize  the  entire  program,  see 
interrelationships  and  dependencies,  and 
recognize  when  delays  are  acceptable.  Thus, 


the  manager  is  better  able  to  assess  problems 
as  the  program  evolves. 

6.1.2  CPM 

The  CPM  scheduling  technique  was  intro¬ 
duced  at  approximately  the  same  time  as 
PERT.  It  was  developed  by  J.  E.  Kelly  of 
Remington-Rand  and  M.  R.  Walker  of 
DuPont  to  aid  in  scheduling  maintenance 
shutdowns  in  chemical  processing  plants. 
Over  the  years,  CPM  has  enjoyed  more  use 
than  any  other  network  scheduling  tech¬ 
nique.  It  is  based  on  the  concept  of  critical 
path  and  was  designed  to  focus  on  the  time 
and  resources,  particularly  cost,  necessary 
to  complete  the  activities  of  a  project. 

Although  CPM  and  PERT  are  conceptually 
similar,  some  significant  differences  exist. 
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most  as  a  result  of  the  type  of  projects  best 
suited  for  each  technique.  As  discussed 
earlier,  PERT  is  better  to  use  when  there  is 
much  uncertainty  and  when  control  over 
time  outweighs  control  over  costs.  PERT 
handles  uncertainty  of  the  time  required  to 
complete  an  activity  by  developing  three 
estimates  and  then  computing  an  expected 
time  using  the  beta  distribution.  CPM  is 
better  suited  for  well-defined  projects  and 
activities  with  little  uncertainty,  where  ac¬ 
curate  time  and  resource  estimates  can  be 
made,  and  the  percentage  of  completion  of 
an  activity  can  be  determined.  In  CPM, 
because  of  the  greater  certainty,  a  single 
time  estimate  is  used.  This  estimate  is  the 
time  plaimed  for  the  activity  under  normal 
conditions;  it  approximates  the  most  likely 
time  estimate  in  PERT.  The  normal  cost 
estimate  is  the  cost  associated  with  finishing 
the  program  in  the  normal  time.  A  second 
time  and  cost  estimate,  the  crash  estimate,  is 
also  used  in  the  CPM  technique.  The  crash 
time  estimate  is  the  time  that  will  be  re¬ 
quired  to  finish  an  activity  if  a  special  effort 
is  made  to  reduce  program  time;  crash  cost 
is  the  cost  associated  with  performing  the 
effort  on  a  crashbasis  so  as  to  reduce  the  time 
to  completion.  This  is  discussed  in  more 
detail  with  a  later  example. 

CPM  is  activity-oriented,  concentrating  on 
activity  start  (early  start,  late  start)  and  fin¬ 
ish  times  (early  finish,  late  finish);  whereas 
PERT  is  event-oriented,  concentrating  on 
early  event  time  and  late  event  time.  The 
network  diagrams  used  for  CPM  and  PERT 
are  essentially  the  same  (see  Eigure  4-3),  as 
are  the  procedures  for  using  them.  As  dis¬ 
cussed  earlier,  certain  actions  are  essential  to 
applying  network  scheduling  techniques. 
The  activities  / events  composing  the  project, 
the  relationships  among  them,  and  their  time 
estimates  must  be  identified,  and  a  network 
diagram  developed.  Once  the  diagram  is 


completed,  the  following  procedures  are 
applied: 

•  Complete  and  aimotate  the  cumula¬ 
tive  time  required  to  reach  each  node  along 
the  paths — This  will  indicate  the  earliest 
time  work  can  start  on  the  next  activity.  The 
final  number  will  indicate  total  time  required 
to  complete  a  particular  path. 

•  Identify  the  critical  path — This  is  the 
sequence  of  events,  or  route,  taking  the  long¬ 
est  time  to  complete. 

•  Starting  at  the  program  completion 
node  on  the  right  side  of  the  diagram,  begin 
working  backward  and  compute  the  latest 
time  an  activity  can  start  without  delaying 
the  overall  program — Eor  example,  if  the 
total  program  takes  40  weeks  and  the  final 
activity  requires  5  weeks,  this  activity  can¬ 
not  begin  later  than  week  35.  Eor  CPM,  the 
difference  between  the  latest  and  earliest 
start  of  an  activity  is  the  slack  or  float.  The 
critical  path  contains  no  slack  or  float  time. 
Eor  PERT,  the  difference  between  the  earli¬ 
est  event  time  and  the  latest  event  time  at 
each  event  is  the  slack/ float  time. 

The  use  of  these  procedures  is  illustrated  in 
a  later  example. 

6.1.3  PDM 

PDM  is  an  activity-oriented  technique  that 
was  developed  subsequent  to  PERT  and 
CPM.  The  impetus  behind  this  develop¬ 
ment  was  the  need  for  greater  flexibility  in 
dealing  with  relationships  and  constraints 
between  project  activities. 

PERT /CPM,  or  the  arrow  diagram  method 
(ADM),  essentially  treats  all  relationships  as 
"finish-to-start"  constraints;  that  is.  Activity 
A  must  be  completed  before  Activity  B  can 
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begin.  There  are  ways  within  PERT  / CPM  to 
circumvent  this  limitation,  but  they  are  cum¬ 
bersome  and  add  more  complexity  to  the 
technique. 

The  PDM  technique  provides  the  capability 
to  treat  other  types  of  relationships  that  oc¬ 
cur  in  complex  projects.  Figure  6-2  shows 
examples  of  these  types  of  relationships  or 
constraints. 

In  addition  to  depicting  different  rela¬ 
tionships  between  activities,  PDM  also 
handles  time  lags  that  would  normally  oc¬ 
cur  as  the  project  progresses.  Examples  of 


such  lags  are  the  time  required  for  the  move¬ 
ment  of  parts  or  components  from  one  activ¬ 
ity  site  to  another,  or  the  time  involved  in 
the  reallocation  of  resources — people,  equip¬ 
ment,  and  facilities.  Figure  6-3  shows  ex¬ 
amples  of  constraint  lags  and  how  they  can 
be  depicted.  These  lags  could  be  repre¬ 
sented  as  activities  in  the  ADM  technique, 
but  this  could  add  needless  complexity  to 
the  schedule.  The  use  of  lags  in  the  PDM 
technique  is  much  less  complicated. 

PDM  uses  the  same  underlying  principles  as 
the  other  networking  techniques:  clearly 
defined  activities,  accurate  time  estimates. 


Figure  6-2.  Example  PDM  Relationships/Constraints 
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critical  path,  etc.  The  difference  between 
PERT/CPM  (ADM)  and  PDM  is  in  the  way 
the  network  is  portrayed.  In  PERT/CPM, 
the  network  nodes  represent  the  events  as¬ 
sociated  with  activities  (i.e.,  the  beginning 
and  end  of  activities),  and  the  connecting 
lines  represent  the  activities  and  the  rela¬ 
tionship/  constraints.  Activity  time  and  re¬ 
source  estimates  are  normally  shown  on  the 


lines.  In  PDM,  the  nodes  represent  the 
estimates,  early  and  late  start  and  finish 
dates,  and  other  appropriate  information 
are  normally  shown  in  the  boxes.  Pigure  6- 
4  is  an  example  of  an  activity  node.  The  lines 
coimecting  the  nodes  represent  the  relation¬ 
ships  between  the  activities,  e.g.,  finish-to- 
start,  start-to-start,  etc.  The  use  of  PDM  is 
demonstrated  in  a  later  example. 


Symbols 


Constraint 

Finish-to-Start  with  Lag 
B  cannot  start  until  5  days  after  A 
is  compieted 


Start-to-Start  with  Lag 
B  cannot  start  untii  7 
days  after  A  has  started 


Finish-to-Start  with  Negative  Lag 
B  cannot  start  until  5  days  before  A 
is  completed 


Figure  6-3.  Example  PDM  Constraints  with  Lag  Time 


Early  Start  Time 

7/12/99 

Eariy  Finish  Time 

7/15/99 

Duration 

3  Days 

Activity  Identification 

Information 

Resource 

Requirements 

Late  Start  Time 

7/14/99 

Late  Finish  Time 

7/17/99 

Figure  6-4.  Example  PDM  Activity  Node 
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6.2  NETWORK  SCHEDULING 
ADVANTAGES  AND 
DISADVANTAGES 

Network  scheduling  techniques  provide  the 
mechanisms  necessary  to  conduct  a  system¬ 
atic,  disciplined,  and  thorough  review  of 
what  will  be  required  to  conduct  and  com¬ 
plete  a  project.  Such  an  approach  is  essential 
for  large,  complex  projects  and  is  also  useful 
in  managing  smaller,  less  complicated 
projects.  The  advantages  and  disadvantages 
of  these  techniques  are  identified  below. 

6.2.1  ADVANTAGES 

•  Provide  graphical  portrayal  of  pro¬ 
ject  activities  and  relationships /con¬ 
straints 

•  Force  communications  among  team 
members  in  identifying  activities 

•  Organize  what  would  otherwise  be 
confusing  material,  making  it  easier  for  man¬ 
agers  to  make  tradeoffs  and  develop  alter¬ 
native  plans 

•  Provide  capabilities  to  evaluate 
progress  and  control  project 

•  Allow  managers  to  predict  shortages 
and  act  on  them  early 

•  Once  prepared,  permit  easy  update 
and  rework 

•  Give  managers  more  control  over 
activities /events  and  schedules 

•  Facilitate  "what  if"  exercises 

•  Provide  the  basis  for  Gantt  and 
milestone  chart  information 


•  Show  resources  associated  with  ac¬ 
tivities  and  time. 

6.2.2  DISADVANTAGES 

•  Network  construction  can  be  diffi¬ 
cult  and  time  consuming. 

•  Only  as  sound  as  the  activity  time 
and  resource  estimates. 

•  Sometimes  difficult  to  portray 
graphically — too  many  lines,  nodes  and 
intersections. 

•  Not  particularly  good  for  conveying 
information  in  briefings/reviews. 

•  Complex  networks,  once  sketched  out 
on  a  large  wall  chart,  tend  to  become  the 
focus  of  management  attention  when,  in 
fact,  a  manager  should  be  paying  attention 
to  factors  not  on  the  chart,  such  as  manage¬ 
ment/labor  relations. 

6.3  HOW  AND  WHEN  NETWORK 
SCHEDULES  ARE  EMPLOYED 

Network  scheduling  techniques  can  be  very 
useful  in  complex  projects  that  involve  new 
technologies  or  processes  and  that  are  not 
repetitive,  such  as  production.  They  are  not 
particularly  easy  to  use  for  presentations 
because  of  their  complexity;  however,  they 
can  be  used  as  the  basis  for  other  scheduling 
techniques  that  are  more  suitable  for  presen¬ 
tation  of  information,  i.e.,  Gantt  or  mile¬ 
stone  charts. 

Government  managers  may  not  use  net¬ 
work  techniques  in  the  day-to-day  manage¬ 
ment  of  their  programs.  However,  they 
should  have  an  understanding  of  the  tech¬ 
niques  to  ensure  that  contractors  are  using 
them  when  appropriate. 
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The  different  types  of  network  scheduling 
techniques  have  many  similarities.  How¬ 
ever,  each  of  them  provides  different  types 
of  information  that  can  be  useful  to  manag¬ 
ers  in  evaluating  progress,  developing 
alternatives,  and  managing  the  allocation  of 
resources  within  their  projects.  The  follow¬ 
ing  examples  show  the  types  of  information 
resulting  from  each  technique  and  how  man¬ 
agers  may  use  them. 

6.3.1  PERT  EXAMPLE 

Figure  6-5  shows  a  PERT  network  for  a 
project  containing  8  activities  (A-H),  with 
the  nodes  1-7  representing  the  begirming 
and  end  of  the  activities.  The  three  time 
estimates  discussed  earlier  in  this  chapter 
are  shown  for  each  activity.  For  example,  for 
Activity  A,  the  time  estimates  are  optimistic 
time=l  week,  most  likely  time=2  weeks,  and 
pessimistic  time=3  weeks.  The  expected 
time  estimate  for  each  activity,  t,  as  derived 
from  the  formula  associated  with  Figure  6-1, 
is  also  shown.  From  this  information,  the 
project  critical  path  can  be  computed  by 
adding  the  time  estimates  along  all  paths 
leading  to  project  completion.  In  this  ex¬ 
ample,  the  critical  path  is  determined  as 
follows: 


Path  A-B-E-H=2+3+2+4=ll  weeks 

Path  A-C-F-H=2-i-4-i-3+4=13  weeks 

Path  A-D-G-H=2+8+9-i-4=23  weeks 

Thus,  path  A-D-G-H  is  the  critical  path 
since  it  requires  the  greatest  time.  Any 
delay  along  this  path  will  cause  a  delay  in 
project  completion.  The  other  paths  are 
shorter  completion.  The  other  paths  are 
shorter  than  the  critical  path  and,  therefore, 
contain  activities  that  can  be  completed  be¬ 
fore  they  are  required.  Therefore,  delays 
along  these  paths  may  not  result  in  delays  in 
project  completion.  In  the  above  example, 
critical  path  activities,  D  and  G,  will  require 
17  weeks  to  complete.  On  path  A-B-E-H, 
activities  B  and  E  will  require  5  weeks  to 
complete.  Thus,  there  will  be  12  weeks  of 
slack  along  that  path.  Actually,  this  slack  is 
only  along  path  B,  E  since  A  and  H  are  on  the 
critical  path.  Likewise  path  C-F  has  10  weeks 
of  slack  time.  This  concept  of  slack  time, 
sometimes  called  float  time  or  path  slack/ 
float,  is  important  because  it  allows  manag¬ 
ers  to  reschedule  activities  not  on  the  critical 
path  to  use  resources  efficiently. 


The  following  description  of  how  slack  time 
is  computed  is  intended  to  illustrate  the 
concept  that  managers  can  use  it  to  their 
advantage.  Fortunately,  software  programs 
compute  slack  time  and  managers  do  not 
have  to  make  these  calculations. 

Slack  time  should  be  computed  for  each 
activity  in  the  network.  One  way  of  doing 
this  is  by  comparing  the  earliest  time  an 
activity  can  begin,  T^,  to  the  latest  time  the 
activity  can  begin,  The  difference  is  the 
activity  slack  time.  For  all  activities  on  the 
critical  path,  T^and  T^^  have  the  same  value. 
To  determine  the  values  of  T,,  and  T,  for  each 
activity,  start  with  the  node  representing  the 
beginning  of  the  first  activity  and  assign  it  a 
value  of  Tg=Tj^=0.  Follow  the  critical  path 
and  add  the  activity  time  estimate  to  the 
value  of  Tg  of  the  preceding  node  to  get  the 
value  of  Tg  for  the  next  node.  For  example, 
the  node  at  the  completion  of  Activity  A  and 
the  begiiming  of  Activity  D  has  a  value  of 
Tg=Tg=2.  Figure  6-6  shows  how  Tg  and  Tg 
can  be  depicted  on  a  network  chart.  Con¬ 
tinue  along  the  critical  path  to  node  7,  which 
has  a  value  of  Tg=Tg=23,  the  time  required  to 
complete  the  project.  Next,  compute  the 
values  for  Tg  for  the  remaining  activities  and 
nodes  not  on  the  critical  path.  The  value  of 


T,,  for  node  3  is  the  value  of  T,,  from  node  2 

h,  h, 

(Tg=2)  plus  the  duration  of  Activity  B;  for 
node  3,  Tg=5. 

To  determine  the  latest  starting  times  for 
each  activity,  begin  at  the  completion  of  the 
project  and  work  backward  through  the  ac¬ 
tivities.  Since  Activity  H  is  on  the  critical 
path,  its  value  of  Tg=19.  Activity  E  is  not  on 
the  critical  path  so  its  value  of  Tg  (shown  on 
node  3)  is  the  difference  between  Tg  at  node 
6  and  the  time  estimate  for  Activity  E,  Tg=19- 
2=17.  The  activity  slack  is  the  difference 
between  Tg  and  Tg  at  each  node.  For  Activity 
E,  the  slack  is  Tg-Tg=17-5=12  weeks.  This 
activity  could  start  anytime  between  weeks 
5  and  17  without  any  adverse  impact  on  the 
critical  path.  Activity  B  is  not  on  the  critical 
path  so  its  value  of  Tg  is  the  difference  be¬ 
tween  Tg  at  node  3  and  the  time  estimate  for 
Activity  B  (17-3=14).  This  is  not  shown  at 
node  2,  since  that  node  also  represents  the 
start  of  Activity  D,  which  is  on  the  critical 
path.  The  slack  for  Activity  B  is  Tg-Tg=14- 
2=12.  (The  same  approach  is  used  to  deter¬ 
mine  the  slack  for  Activity  C.)  Slack  is  not 
additive  along  a  path;  it  must  be  shared  by 
all  activities  on  the  path.  Thus,  if  Activity  B 
starts  at  week  5  instead  of  week  2,  Activity  E 
would  have  only  9  weeks  of  slack  available. 


Te=5 

P=17 


Tl=10 


Figure  6-6.  PERT  Example  with  Slack  Time 
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Similarly,  Activities  C  and  F  have  a  slack  of 
10  weeks. 

The  concept  of  slack  and  and  can  be 
very  useful  to  managers,  providing  the  basis 
for  resource  allocation  and  also  providing 
the  means  to  determine  the  probability  of 
meeting  the  project  schedule.  This  latter 
topic  is  beyond  the  intended  scope  of  this 
guidebook;  however,  a  number  of  available 
books  provide  detailed  discussion  of  the 
application  of  PERT  techniques.  (See  the 
bibliography  in  Appendix  D.) 

6.3.2  CPM  EXAMPLE 

As  discussed  earlier,  PERT  and  CPM  are 
conceptually  similar,  in  thatboth  techniques 
use  the  same  type  of  network  structure,  and 
the  concepts  of  critical  path  and  slack  time. 
The  following  example  will  be  used  to  illus¬ 
trate  basic  application  of  the  CPM  technique. 
Figure  6-7  shows  the  same  project  as  used  in 
the  PERT  example,  with  the  single  time  esti¬ 
mates  for  each  activity.  Table  6-1  shows  the 


time  and  crash  estimates  for  each  of  the 
activities. 

The  critical  path  for  the  CPM  approach  is 
determined  in  the  same  way  as  in  the  PERT 
example.  While  the  concept  of  slack  time 
is  essentially  the  same  as  in  PERT,  it  is  nor¬ 
mally  calculated  in  a  different  maimer  using 
four  different  values  for  each  activity: 

•  Earliest  time  the  activity  can  start,  ES 

•  Earliest  time  the  activity  can  finish,  EF 

•  Latest  time  an  activity  can  start,  LS 

•  Latest  time  an  activity  can  finish,  LF. 

To  compute  ES,  start  at  the  first  activity  and 
move  forward  through  the  network  paths. 
The  earliest  Activity  A  can  start  is  at  t=0. 
The  earliest  that  it  can  finish  is  ES  plus  the 
activity  duration;  thus  for  A,  ES=0  and  EF=2. 
The  earliest  start  for  subsequent  activities  is 
the  EF  of  the  preceding  activity.  For  Activity 
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B,  ES=2.  The  earliest  finish  time  for  each 
activity  is  the  earliest  start  time  plus  the  activ¬ 
ity  duration.  For  Activity  B  this  is  EF=2+3=5. 
When  activities  converge,  such  as  E,  F,  and  G 
at  node  6,  the  earliest  starting  time  for  the  next 
activity  is  the  latest  value  of  EE  of  the  preced¬ 
ing  converging  activities. 

To  compute  the  latest  times,  make  a  back¬ 
ward  pass  through  the  network,  beginning 
with  the  last  activity.  The  date  to  begin  the 
pass  can  be  either  an  established  required 
date  or  the  early  finish  date  for  the  project 
completion.  The  latest  starting  date  for  the 
final  activity  is  determined  by  subtracting  the 
activity  duration  from  the  date  used  to  begin 
the  pass.  For  subsequent  activities,  the  latest 
finish  date  is  the  same  as  the  latest  starting 
date  for  the  preceding  activity.  In  the  back¬ 
ward  pass,  the  value  of  LF  for  an  activity  that 
precedes  a  set  of  diverging  activities  in  the 
network  (activity  A  in  the  example)  is  the 
earliest  of  the  values  of  LS  of  the  diverging 
activities  (B,  C,  D). 

The  values  of  ES,  EE,  LS,  and  LF  for  all  activi¬ 
ties  are  shown  in  Figure  6-7.  With  this  infor¬ 
mation,  one  can  determine  the  slack  for  each 
activity.  Slack  is  determined  using  the  fol¬ 
lowing  formula:  Slack=LF-EF=LS-ES. 

The  relative  certainty  of  time  and  resource 
estimates  enables  managers  to  determine  the 
percent  of  work  completed  in  each  activity  as 
the  project  progresses.  Being  able  to  estimate 
the  percent  of  completion  provides  manag¬ 
ers  with  the  means  to  redistribute  resources  if 
an  activity  is  falling  behind  schedule.  For 
example,  if  an  activity  has  f  allenbehind  sched¬ 
ule,  it  is  possible  to  estimate  the  work  remain¬ 
ing  and  the  cost  of  applying  additional  re¬ 
sources  to  complete  the  activity  on  schedule. 
Network  scheduling  techniques,  particularly 
CPM,  used  on  projects  with  relatively  cer¬ 
tain  time  and  cost  estimates  can  provide 


managers  with  information  to  effectively 
manage  their  projects.  Using  percent  of 
work  completed  or  that  is  remaining  on 
ongoing  activities,  they  can  compare  the 
progress  at  a  certain  time  with  the  original 
plan.  Based  on  this  information,  they  can 
develop  revised  time  and  cost  estimates  for 
these  activities  and  forecast  new  start  and 
completion  dates  for  remaining  activities 
and  a  new  project  completion  date.  They 
can  then  use  the  new  forecast  dates  to  deter¬ 
mine  action  that  can  be  taken  and  the  appro¬ 
priate  resource  plaiming  and  reallocation,  if 
necessary. 

The  CPM  technique  provides  managers  with 
the  means  to  investigate  ways  and  impacts 
of  speeding  up,  or  crashing,  the  schedule. 
As  part  of  the  plaiming  process,  a  set  of  crash 
estimates  should  be  developed  if  possible. 
The  estimates  for  this  example  are  shown  in 
Table  6-1. 

This  table  shows  the  time  and  cost  estimates 
and  the  crash  cost  per  week.  To  crash  a 
schedule,  some  key  points  must  be  consid¬ 
ered: 

•  Crash  only  along  the  critical  path. 

•  When  an  activity  is  shortened,  one  or 
more  new  critical  paths  may  emerge. 

•  Parallel  critical  paths  increase  risk 
dramatically. 

•  Generally,  least  additional  cost  is  the 
criterion  used  to  select  which  activity  to 
crash,  but  other  considerations  (e.g.,  per¬ 
sonnel  hours)  could  be  used. 

In  this  example,  assume  that  the  project  must 
be  crashed  by  4  weeks  at  the  least  additional 
cost.  Looking  at  the  activities  on  the  critical 
path,  select  the  one  with  the  lowest  weekly 
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crash  cost;  in  this  case  it  is  Activity  D,  which 
can  be  crashed  from  8  to  6  weeks  for  an 
additional  $6,000.  Next,  crash  Activity  G  by 
2  weeks  at  a  cost  of  $10,000.  Reducing  both 
of  these  activities  does  not  change  the  criti¬ 
cal  path. 

6.3.3  PDM  EXAMPLE 

The  PDM  technique  focuses  on  program 
activities  and  the  meaning  of  the  constraints 
among  activities.  This  technique  is  used  in 
many  scheduling  software  applications,  and 
it  relies  on  the  same  concepts — critical  path, 
slack  time,  etc.,  as  the  other  network  sched¬ 
uling  techniques. 

Figure  6-8  shows  a  PDM  network  for  a  project 
with  Activities  A-I.  (Assume  that  the  unit  of 
working  time  (duration)  is  one  week.)  Note 
that  Activity  B  caimot  start  until  Activity  A 
starts,  and  Activity  D  caimot  end  until  Ac¬ 
tivity  C  ends.  The  critical  path  is  determined 
in  essentially  the  same  way  as  in  other  net¬ 
works.  In  PDM,  however,  one  must  account 
for  the  different  types  of  constraints.  In  this 
example.  Activities  B  (duration=4)  and  D 


(duration=2)  will  require  6  weeks  to  com¬ 
plete.  However,  Activity  D  can  not  be  com¬ 
pleted  until  Activity  C  is  finished,  which  is  9 
weeks  (5  weeks  for  Activity  A  and  4  weeks 
for  C).  The  difference  between  the  9  and  6 
weeks  (i.e.  3  weeks)  must  be  added  to  the 
time  to  complete  Activity  D  when  determin¬ 
ing  the  critical  path.  This  is  shown  below  in 
the  parenthetical  term  for  Path  B-D-G-I.  The 
critical  path  for  this  example  is  determined 
as  follows: 

Path  A-G-F-I  =  5-i-4-i-5-i-3  =  17  weeks 

Path  B-D-G-I  =  4+(2+3)+2+3  =  14  weeks 

Path  B-E-H-I  =  4-i-5-f-2+3  =  14  weeks 

Thus,  Path  A-G-F-I  is  the  critical  path. 

The  slack  times  for  the  activities  are  deter¬ 
mined  in  the  same  way  as  in  the  GPM  tech¬ 
nique,  using  earliest  and  latest  start  and 
finish  times,  ES,  EF,  LS,  LF.  Earliest  times  are 
computed  by  making  a  forward  pass  through 
the  networks  paths,  and  latest  times  are 
determined  making  a  backward  pass.  Fig- 
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ure  6-9  shows  the  PDM  network  with  these 
values,  using  the  activity  format  shown  in 
Figure  6-4.  The  values  of  ES,  EE,  LS,  and  LF 
in  Figure  6-9  represent  the  beginning  of  the 
unit  of  work  time,  in  this  case  a  week;  e.g.,  ES 
for  Activity  A  is  the  beginning  of  week  1, 
while  EE  is  the  begiiming  of  week  6.  (The 
begirming  of  week  6  corresponds  to  the  end 
of  week  5.)  The  earliest  and  latest  finish 
dates  for  this  project ,  Activity  I,  is  the  begin¬ 
ning  of  week  1 8,  or  the  end  of  week  1 7.  U sing 
the  formula  for  slack. 

Slack  =  LS  -  ES  =  LF  -  EE, 

we  see  that  on  path  B  -  D  -  G  - 1,  activities  B, 
D,  and  G  each  have  a  slack  of  3  weeks.  This 
slack  is  not  additive;  if  Activity  D  starts  at 
week  9  vice  week  8,  then  Activity  G  has  only 
2  weeks  of  slack  remaining.  We  also  see  that 
Activities  B,  E,  and  H  have  3  weeks  of  slack 


on  their  path.  If  Activity  B  uses  3  weeks  of 
slack,  none  will  be  left  for  either  path. 

The  above  example  assumes  that  progress¬ 
ing  from  one  activity  to  the  next  requires 
zero  time,  which  in  most  projects  is  unreal¬ 
istic.  The  concept  of  lag  time  can  be  used  to 
incorporate  the  time  required  to  transition 
from  one  activity  to  another,  such  as  ma¬ 
chine  set-up  time  or  movement  of  material, 
parts,  or  components  from  one  site  to  an¬ 
other.  Lag  time  can  be  shown  on  the  net¬ 
work  and  must  be  accounted  for  in  deter¬ 
mining  critical  path  and  values  of  ES,  EE,  LS 
and  LF.  Figure  6-10  shows  that  in  moving 
from  Activity  D  to  Activity  G,  there  will  be  a 
lag  of  1  week.  The  figure  also  shows  the 
effect  of  this  lag  time  on  the  earliest  and 
latest  start  times  and  on  finish  times.  The 
resulting  slack  for  Activities  D  and  G  is  now 
2  weeks.  This  example  shows  that  the  PDM 


Figure  6-8.  PDM  Example 


47 


Figure  6-9.  PDM  Example — Early  and  Late  Start  and  Finish  Times 


Figure  6-10.  PDM  Example  with  Lag  Time 


FOOTNOTES 

Note:  The  numbering  convention  used  in  this  PDM  network  is  similar  to  the  CPM  network  in  Figure  6-7;  it  is 
described  on  page  46.  Each  computer  scheduling  program  uses  one  (or  gives  a  choice)  of  methods  to  relate 
duration  to  the  time  unit. 
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technique  provides  considerably  greater  flex¬ 
ibility  in  handling  different  types  of  con¬ 
straints  than  does  ADM  (PERT  and  CPM). 
Consequently,  it  is  better  suited  for  use  in 
complex  projects,  particularly  those  with 
many  parallel  activities  and  constraints  other 
than  finish-to-start. 

6.4  NETWORK  SCHEDULING  WHEN 
RESOURCES  ARE  LIMITED 

In  the  previous  discussion,  the  assumption 
was  that  a  new  activity  could  start  as  soon  as 
any  constraints  were  satisfied  because  suffi¬ 
cient  resources  were  available  to  perform 
the  work.  In  practice,  however,  resources  to 
proceed  are  not  always  available. 

In  those  situations.  Program  Managers  can 
take  one  or  more  different  actions  to  reduce 
the  adverse  impact  on  the  program.  Those 
actions  include: 

•  Adding  additional  resources 

•  Reducing  the  scope  of  the  program 

•  Adjusting  the  schedule  to  accommo¬ 
date  the  resource  shortfall 

In  this  section,  we  show  how  network  sched¬ 
ules  and  the  concepts  of  critical  path  and 
slack  (float)  can  be  applied  to  make  better 
use  of  limited  resources.  Pigure  6-11  shows 
a  PDM  network  with  activities  A  through  J. 
Each  node  of  the  network  shows  the  number 
of  people  required  to  complete  the  activity 
along  with  the  activity  duration  (in  weeks) 


and  earliest  and  latest  start  and  finish  times, 
represented  as  the  begiiming  of  the  unit  of 
work  time  (week). 

To  determine  the  adequacy  of  resources 
(people  in  this  example),  assume  that  each 
activity  will  start  as  early  as  possible  and 
determine  the  resource  requirements  over 
time.  Pigure  6-12  shows  the  persoimel  load¬ 
ing  requirements  by  time  for  the  duration  of 
the  program.  During  week  one,  11  people 
are  required  to  work  on  activities  A,  B,  and 
C.  Now,  let's  suppose  only  nine  people 
are  available  to  work  during  this  11  week 
period.  The  chart  shows  there  will  not  be 
sufficient  workers  during  the  first,  fourth, 
and  fifth  weeks.  There  will  be  sufficient 
workers  to  perform  the  work 
scheduledduring  the  second  and  sixth  week. 
During  the  third  and  seventh  throughout 
eleventh  weeks,  there  will  be  a  surplus  of 
workers  for  the  work  scheduled.  The  task 
becomes  one  of  rearranging  the  schedule  so 
that,  insofar  as  possible,  the  peaks  and  val¬ 
leys  are  evened  out  without  scheduling  more 
work  than  nine  people  can  do.  In  this  ex¬ 
ample,  this  rearrangement  can  be  accom¬ 
plished  quickly  by  hand.  However,  with 
many  activities,  it  becomes  very  difficult  to 
find  the  optimum  answer.  Portunately, 
scheduling  software  applications  are  avail¬ 
able  to  assist  in  solving  the  problem.  Re¬ 
gardless  of  the  approach  used  (manual  or 
automated),  the  resource-leveling  process  is 
an  iterative  step-by-step  process  using  a  set 
of  rules  to  establish  the  priority  of  the  activi¬ 
ties  requiring  the  constrained  resource,  and 
the  actions  to  be  taken. 
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Figure  6-11.  Network  Schedule  with  Constrained  Resources 


Figure  6-12.  Personnel  Loading  Chart 
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As  discussed  earlier,  the  concept  of  float  (or 
slack)  can  be  useful  in  the  efficient  allocation 
of  resources,  and  it  should  be  considered  in 
establishing  the  rules  to  be  followed.  The 
float  demonstrated  in  earlier  examples  is 
commonly  called  path  float.  Another  type 
of  float  that  is  particularly  useful  in  resource 
allocation  is  free  float.  Free  float  is  the  slack 
that  a  single  activity  can  experience  without 
affecting  any  other  activity.^  The  free  float  of 
a  given  activity  is  defined  as  the  difference 
between  earliest  start  of  the  succeeding  ac¬ 
tivity  and  earliest  finish  of  the  given  activity. 
In  our  example,  the  free  float  for  Activity  D 
is  FF(D)=ESa)-EF(D)10-5=5. 

In  this  example,  the  approach  is  to  find 
activities  having  the  most  free  float  and  try 
to  delay  them  as  long  as  possible  without 
delaying  the  entire  program.  By  delaying 
the  start  of  Activity  C  for  2  weeks_(to  the 
begiiming  of  week  3),  Activities  A  and  B  can 
begin  simultaneously  without  exceeding  the 
limit  of  nine  workers.  Similarly,  Activities 
D,  Ef,  and  I  can  be  delayed,  resulting  in  the 
revised  persoimel  loading  chart  shown  in 
Figure  6-13. 

Figure  6-14  shows  the  revised  schedule  us¬ 
ing  lag  times  to  reflect  the  delays.  Note  that 
Activity  A  has  a  start-start  relationship  with 
Activity  B.  The  "Lag  0"  constraint  indicates 
that  A  should  start  when  B  starts.  Any  delay 
in  starting  Activity  A  will  result  in  a  person¬ 


nel  shortage  as  the  project  progresses.  It  may 
not  alwaysbe  possible  to  rearrange  the  sched¬ 
ule  to  stay  within  the  resource  constraints. 
In  those  cases,  other  steps,  such  as  adding 
more  resources  or  extending  the  schedule, 
will  have  to  be  taken  to  minimize  the  ad¬ 
verse  impact  on  the  program. 

6.5  SUMMARY 

Network  scheduling  techniques  (PERT, 
CPM,  and  PDM)  are  much  alike  in  provid¬ 
ing  such  things  as  interdependencies,  depth 
of  detail,  a  critical  path,  and  slack.  The 
choice  among  these  three  techniques  de¬ 
pends  primarily  on  the  type  of  program  and 
managerial  objectives.  The  PERT  method  is 
particularly  useful  if  there  is  considerable 
uncertainty  in  program  activity  times  and  if 
control  of  the  program  schedule  outweighs 
other  factors.  On  the  other  hand,  CPM  is 
more  appropriate  when  activity  times  can 
be  adjusted  readily  and  when  it  is  important 
to  plan  an  appropriate  tradeoff  between  pro¬ 
gram  time  and  cost.  The  PDM  technique  is 
best  suited  for  complex  projects  with  differ¬ 
ent  types  of  relationships /constraints  be¬ 
tween  activities.  In  reality,  the  proliferation 
of  scheduling  software  has  blurred  many  of 
the  differences  among  network  scheduling 
techniques  as  well  as  Gantt  and  milestone 
techniques. 
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Figure  6-13.  Revised  Personnei  Loading  Chart 


1  3 
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6-14.  Revised  Network  Scheduie  with  Constrained  Resources 
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7 

PRODUCTION  SCHEDULING 


7.1  DESCRIPTION 

The  scheduling  techniques  discussed  in 
the  previous  chapters  are  best  suited  for 
one-time  development  projects.  Produc¬ 
tion  scheduling,  as  its  name  implies,  fo¬ 
cuses  on  the  plaiming,  execution,  and  con¬ 
trol  of  repetitive  activities,  such  as  those 
involved  in  the  manufacture  of  several  iden¬ 
tical  items  using  the  same  processes.  The 
objective  of  production  scheduling  is  to 
balance  the  materials  required  to  produce 
the  items  with  the  production  process  and 
the  delivery  schedule.  Such  scheduling  is 
essential  to  the  efficient  use  of  all  resources 
and  facilities  involved  in  the  manufactur¬ 
ing  process. 

While  the  principles  of  planning  and  sched¬ 
uling  are  essentially  the  same  for  both  situa¬ 
tions,  there  are  differences  that  should  be 
considered.  For  example,  in  the  develop¬ 
ment  phase,  planning  and  scheduling 
should  reflect  the  uncertainty  inherent  in 
development  of  the  product  and  processes 
used.  Consequently,  plaiming  and  sched¬ 
uling  should  permit  sufficient  flexibility  to 
allow  for  redesign  and  retest  when  inevi¬ 
table  problems  arise.  In  production,  there 
is  less  uncertainty;  the  design  is  relatively 
stable  and  the  processes  to  be  used  are 
fairly  well-defined.  In  general,  more  de¬ 
finitive  constraints  exist  in  production 
scheduling,  such  as  quantities  to  be  pro¬ 
duced,  required  delivery  dates,  and  ca¬ 
pabilities  and  availability  of  production 
assets. 


Production  planning  and  scheduling 
should  be  very  detailed.  A  top-level  project 
schedule  should  serve  as  the  production 
baseline.  It  should  reflect  the  integration  of 
activities  that  different  organizations  in¬ 
volved  in  the  production  process  conduct — 
tooling,  material  procurement,  etc.  Lower 
tier  schedules  should  be  developed  for 
each  of  the  manufacturing  activities,  with 
special  attention  to  those  having  potential 
impact  on  the  delivery  schedule,  e.g.,  ma¬ 
terial  procurement;  tool  design,  fabrica¬ 
tion,  and  prove-out;  test  equipment  prove- 
out;  and  capital  equipment  procurement. 
Thorough  planning  and  integration  of  all 
production  process  activities  are  essential 
to  manage  risk  in  the  manufacturing  ap¬ 
proach.  This  also  provides  assurance  that 
necessary  resources  will  be  available  when 
needed,  that  no  resources  will  be  over¬ 
loaded  or  completely  expended  during 
execution  of  any  manufacturing  task,  and 
that  product  delivery  dates  are  achievable. 

An  understanding  of  the  production  pro¬ 
cesses,  to  include  such  things  as  the  se¬ 
quence  of  operations,  make  or  buy  deci¬ 
sions,  inspection  methods,  tooling,  etc.,  is 
critical  to  effective  production  planning 
and  scheduling.  The  planning  and  sched¬ 
uling  of  all  activities  must  be  fully  inte¬ 
grated  and  reflect  a  synchronized  flow  of 
events  that  result  in  product  or  process 
completion  when  required.  The  produc¬ 
tion  schedule  describing  and  integrating 
such  things  as  the  acquisition  of  required 
materials,  fabrication  flow,  process  times. 
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plant  facilities  to  be  used,  and  personnel 
skills  required  should  be  developed  as 
early  as  possible  in  the  development  pro¬ 
cess  and  included  in  the  manufacturing 
plan. 

Once  the  plaiming  and  scheduling  are  com¬ 
plete  and  production  begins,  managers 
need  the  means  to  monitor  progress  and  to 
identify  problem  areas  in  the  process  that 
could  adversely  affect  the  delivery  sched¬ 
ule.  A  technique  that  is  commonly  used  for 
this  purpose  is  the  Line  of  Balance  (LOB) 
technique.  It  graphically  portrays  the  key 
activities  of  the  production  plan  relative  to 
a  required  delivery  schedule  and  provides 
a  view  of  the  progress  being  made  in  each 
activity.  This  enables  managers  to  focus 
their  attention  on  specific  problem  areas  in 
the  process. 

Government  PMs,  except  those  associated 
with  an  activity  that  builds  or  re-builds 
equipment,  will  never  be  responsible  for 
developing  a  production  schedule.  How¬ 
ever,  they  should  understand  the  process 
of  creating  one  because  the  success  of  a 
program  is  very  dependent  upon  the  pro¬ 
ducer  to  plan,  schedule,  and  implement  a 
production  plan. 

The  ensuing  discussion  provides  a  basis 
for  understanding  the  fundamentals  of 
production  planning  and  monitoring.  Most 
companies  have  tailored  plaiming  software 
programs  to  fit  their  needs,  however  the 
principles  are  the  same  as  those  used  in  the 
LOB  approach.  For  that  reason,  LOB  is  the 
subject  of  discussion. 

The  LOB  technique  consists  of  four  ele¬ 
ments  as  described  below  and  shown  in 
Figure  7-1.  The  application  and  use  of  this 
technique  is  demonstrated  in  a  later  sec¬ 
tion  of  this  chapter. 


7.1.1  Objective  Chart 

An  Objective  Chart  (Figure  7-1  A)  is  a  dis¬ 
play  of  the  cumulative  contract  delivery 
schedule  over  time.  It  shows  cumulative 
units  on  the  vertical  scale  and  dates  of 
delivery  along  the  horizontal  scale.  It  also 
shows  actual  cumulative  deliveries  to  date. 

7.1.2  Production  Plan  Chart 

This  chart  (Figure  7-lB)  shows  the  major 
production  process  activities  and  events 
(control  points)  that  are  to  be  monitored 
using  this  technique.  It  also  shows  the  lead- 
time  associated  with  each  of  the  control 
points. 

The  more  steps  that  are  monitored,  the  more 
sensitive  and  more  complicated  the  chart 
becomes.  Generally,  control  points  on  a 
single  chart  should  be  limited  to  50.  If  there 
are  more  than  50,  subsidiary  production 
plans  canbe  used  to  feed  the  top  plan.  Thus, 
each  chart  can  be  kept  simple  and  easy  to 
understand.  The  shipping  date  of  subsid¬ 
iary  charts  is  the  point  at  which  a  subpro¬ 
gram  must  be  ready  to  join  the  overall 
schedule. 

On  the  production  plan  chart,  each  moni¬ 
tored  step  is  numbered,  left  to  right.  Step  1 
has  the  longest  lead  time;  the  shipping  date 
is  the  highest-numbered  step.  When  two 
steps  are  done  at  the  same  time,  they  are 
numbered  from  top  to  bottom,  such  as  steps 
8, 9,  and  10.  These  control  points  can  also  be 
given  symbols  that  show  whether  they  in¬ 
volve  purchased  items,  subcontracted  parts, 
or  parts  and  assemblies  produced  in-house. 
Assemblies  break  down  into  subassemblies, 
which  break  down  into  parts  or  operations. 
Thus,  one  can  develop  a  production  plan 
for  any  part  or  level  of  assembly. 
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Figure  7-1 .  Line  of  Baiance  Technique 


The  production  plan  chart  shows  the 
interrelationships  and  the  sequence  of 
major  steps,  as  well  as  lead  times  required 
for  each  step.  An  understanding  of  the 
manufacturing  processes  involved  and 
sound  judgment  are  required  to  know 
which  step  and  how  many  steps  must  be 
monitored.  Slack  or  float  times  for  activi¬ 
ties  are  not  considered  when  plotting  the 
production/lead-time  chart;  only  the  esti¬ 
mated  time  (and  latest  finish  point)  for 
each  activity  is  used. 

The  12  control  points  in  the  production 
plan  chart  shown  in  Figure  7-lB  represent 
key  tasks  in  manufacturing  one  lot  of  mis¬ 
siles.  The  plan  indicates  that  control  point 

(1),  fabricate  ballistics  shell,  must  begin  24 
workdays  before  1  January  to  meet  the  first 
scheduled  delivery  of  five  units  by  the  end 
of  December  (see  the  objective  chart).  The 
lead  time  for  other  control  points  can  be 
related  to  the  scheduled  delivery  in  a  simi¬ 
lar  maimer.  Time  for  in-house  transfer  and 
storage  must  be  allowed  in  addition  to  the 
processing  time. 

7.1.3  Program  Status  Chart 

This  chart  (Figure  7-lC)  shows  the  cumula¬ 
tive  inventory  status  at  each  control  point  in 
the  process  at  a  given  time  (in  this  case,  1 
May).  Looking  at  control  point  12,  we  see 
that  the  government  has  accepted  14  units  of 
theproduct.  Thebar  for  controlpotnt9  shows 
that  40  units  of  the  guidance  section  have 
been  assembled,  and  the  bar  for  control  point 
4  shows  that  in-house  fabrication  has  begim 
on  60  fins. 

The  cumulative  numbers  of  units  through 
every  control  point  can  and  should  be  meas¬ 
ured  monthly.  Final  deliveries  (government 
acceptances)  are  shown  month-by-month  on 
the  objective  chart  as  actual  deliveries. 


7.1.4  Line  of  Balance 

The  LOB  represents  the  number  of  units  that 
should  have  passed  through  each  control 
point  (cumulatively)  to  satisfy  the  contract 
delivery  schedule.  Managers  use  it  to  ana¬ 
lyze  how  the  status  of  each  control  point  on  a 
given  date  will  affect  future  schedules.  This 
LOB  is  drawn  on  the  Program  Status  Chart 
(Figure  7-lC)  using  the  following  procedures: 

(1)  Select  a  control  point;  for  example,  7. 

(2)  From  the  production  plan/lead-time 
chart  (Figure  7-lB),  determine  the  lead  time — 
the  time  from  control  point  7  to  the  shipment 
point.  Government  Acceptance  (12 
workdays). 

(3)  U sing  this  number,  determine  the  date 
that  the  unit  now  at  control  point  7  should  be 
completed.  (May  1-1-12  workdays = just  over 
halfway  through  a  22-workday  month.) 

(4)  Find  the  point  corresponding  to  this 
date,  approximately  May  17,  on  the  contract 
schedule  line  and  determine  how  many  units 
scheduled  for  completion  this  represents  by 
moving  horizontally  from  the  objective  chart 
to  the  program  status  chart  (they  share  the 
same  vertical  scale). 

(5)  Draw  a  line  on  the  program  status 
chart  (Figure  7-lC)  at  the  level  (43  units)  over 
control  point  7. 

(6)  Repeat  the  above  for  each  control 
point  and  connect  the  horizontal  lines  over 
the  control  points.  The  resulting  line  is  the 
LOB,  indicating  the  quantities  of  (1)  units 
that  should  have  passed  through  each  con¬ 
trol  point  on  the  date  of  the  study  or  inven¬ 
tory  (1  May)  if  the  contract  delivery  schedule 
were  being  met. 
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The  difference  between  the  LOB  and  the 
top  of  the  bar  for  each  control  point  is  the 
number  of  units  behind  or  ahead  of  sched¬ 
ule  as  of  1  May.  Thus,  control  point  12  is  16 
units  behind  schedule,  control  point  9  is  5 
units  ahead  of  schedule,  and  control  point 
7  is  21  units  behind  schedule.  The  main 
impact  of  control  point  7  being  behind 
schedule  will  be  felt  in  12  workdays,  which 
is  the  lead  time  for  control  point  7.  As  of  1 
April,  an  insufficient  number  of  air  vehicle 
components  (shell,  fins,  engine)  had  passed 
into  the  assembly  (air  vehicle  body)  phase. 
This  will  adversely  affect  final  deliveries 
12  workdays  hence.  All  other  control  points 
can  be  analyzed  in  the  same  way. 

7.2  WHEN  AND  HOW  TO  USE  THE 
LINE  OF  BALANCE  TECHNIQUES 

7.2.1  General 

The  LOB  technique  should  be  considered 
for  use  in  any  project  requiring  the  manu¬ 
facture  of  a  specific  quantity  of  a  product 
using  repetitive  processes.  It  is  an  effective 
technique  for  identifying  those  activities 
that  require  attention  and  possibly  correc¬ 
tive  action  and  can  also  be  used  for  report¬ 
ing  the  status  of  the  manufacturing  process 
and  delivery  schedule  to  higher  manage¬ 
ment.  The  LOB  charts  should  be  updated 
on  a  periodic  basis  (weekly  or  monthly, 
depending  on  such  factors  as  the  size  of  the 
production  run,  the  number  of  activities  / 
control  points,  and  the  level  of  automated 
data  management). 

Government  managers  will  probably  not 
be  involved  with  the  LOB  technique  in  the 
day-to-day  management  of  their  programs. 
However,  they  should  have  a  basic  under¬ 
standing  of  the  technique,  the  type  of  infor¬ 
mation  it  can  convey,  and  its  applicability. 


7.2.2  Analysis 

Using  the  LOB  charts  in  Figure  7-1,  man¬ 
agement  can  tell  at  a  glance  how  actual 
progress  compares  with  plaimed  progress. 
Analysis  of  the  charts  can  pinpoint  prob¬ 
lem  areas.  Delays  at  control  point  7  in  the 
example  may  have  been  causing  final  de¬ 
livery  problems  throughout  the  contract. 
However,  the  purpose  of  LOB  analysis  is 
not  to  show  what  caused  the  slippage  in 
the  shipping  date,  but  to  detect  potential 
future  problems. 

In  the  example,  the  Government  accep¬ 
tance  point  is  control  point  12.  The  bar 
doesn't  reach  the  LOB;  therefore,  deliver¬ 
ies  are  behind  schedule.  Control  points  10 
and  11  are  short.  However,  point  9  is  on 
schedule.  Since  point  10  depends  on  points 
8  and  9,  we  know  control  point  8  is  the 
offender.  Both  points  7  and  8  are  short,  but 
there  are  more  than  enough  purchased 
items  (engines)  at  control  point  6. 

What's  the  problem  with  control  point  8? 
Trace  it  back  to  control  point  7,  which  is 
seriously  short.  It  is  obvious  that  not  hav¬ 
ing  enough  completed  fins  is  holding  up 
the  whole  process.  Control  points  2, 3  and 
5  are  short,  but  are  not  directly  responsible 
for  the  failure  to  meet  the  delivery  sched¬ 
ule  since  9  is  ahead  of  schedule.  Neverthe¬ 
less  shortages  at  2,  3,  and  5  could  soon 
cause  problems  at  9.  The  problem  with  the 
fins  7  should  be  addressed  before  manage¬ 
ment  attention  is  devoted  to  other  short 
operations.  The  overages  at  control  points 
1  and  6  may  be  examined  from  the  point  of 
view  of  inventory  control.  Updating  the 
charts  requires  a  good  status-reporting  sys¬ 
tem,  which  can  be  mechanized  if  the  pro¬ 
gram  is  large  and  complex. 
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7.3  LINE  OF  BALANCE  ADVANTAGES 
AND  DISADVANTAGES 

7.3.1  Advantages 

(1)  Points  out  problems  before  their 
impact  on  finished  product  deliveries  show 
up,  thereby  allowing  managers  to  correct 
problems  earlier. 

(2)  Allows  managers  to  see,  in  the 
middle  of  a  contract,  whether  they  can  meet 
the  contract  schedule  if  they  continue  work¬ 
ing  as  they  have  been. 

(3)  Focuses  attention  on  those  pro¬ 
duction  control  points  where  there  are  prob¬ 
lems;  this  allows  a  senior  manager  to  pin¬ 
point  responsibility  for  slippages. 

7.3.2  Disadvantages 

(1)  People  working  on  a  project  may 
not  grasp  what  the  LOB  is  measuring. 

(2)  Limited  to  production  and/or 
assembly-type  processes. 

(3)  Shows  only  where  the  problem  is, 
not  what  it  is. 

(4)  A  monitoring  device ;  not  as  easy 
to  use  as  a  plaiming  device. 

7.4  SUMMARY 

The  LOB  is  a  monitoring  technique  that 
gives  prior  warning  of  problems  within  a 
continuous  production  process.  The  key  is 
to  catch  problems  in  a  production  process 
early;  otherwise,  the  schedule  is  lost.  The 
LOB  technique  provides  that  warning. 


Think  of  the  production  process  as  a  natu¬ 
ral  gas  pipeline.  If  a  bubble  of  air  gets 
into  the  pipeline,  it  will  eventually  be 
carried  to  the  gas  users,  and  the  users 
will  find  their  burners  extinguished  as 
the  nonflammable  air  reaches  them.  The 
manager  of  the  pipeline  company  or  the 
natural  gas  utility  doesn't  want  clients  to 
suffer  blowouts  from  air  bubbles  in  their 
lines.  The  same  holds  true  for  the  manag¬ 
ers  of  a  continuous  production  process. 
Waiting  for  problems  to  show  up  at  the 
end  of  the  line  is  a  mistake.  Problems 
need  to  be  detected  when  they  begin  so 
corrections  are  faster,  before  too  much 
damage  (to  cost,  performance,  or  sched¬ 
ule)  is  done,  and  production  schedules 
fall  too  far  off  contract. 

To  do  LOB,  the  following  is  needed:  (1)  a 
contract  schedule,  or  objective  chart;  (2)  a 
production  plan  or  lead-time  chart  for 
the  production  process  itself;  (3)  control 
points  cumulative  inventories;  and  (4)  a 
program  status  chart  on  which  to  plot 
LOB  and  the  cumulative  quantities  of 
units  that  have  passed  through  the  con¬ 
trol  points  of  the  assembly /production 
process.  If  the  objective  and  program 
status  charts  are  given  the  same  vertical 
scale,  the  LOB  can  be  plotted  graphically 
from  the  former  to  the  latter. 

Remember  that  the  shape  of  the  LOB  will 
change  over  time,  especially  if  the 
production  process  has  a  beginning  and 
an  end.  Remember,  too,  that  LOB  charts 
show  where  a  problem  is,  but  not  neces¬ 
sarily  why  the  problem  exists  or  what  the 
solution  is. 
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8 

TIME  MANAGEMENT 


In  most  programs,  especially  in  DoD  and 
defense-related  industries,  time  is  a  re¬ 
source  that  must  be  carefully  managed.  If 
it  is  not,  it  can  become  a  serious  constraint 
that  can  threaten  the  success  of  the  pro¬ 
gram.  This  chapter  addresses  time  man¬ 
agement  from  two  perspectives:  first,  as  it 
relates  to  a  program,  and  second,  as  it 
relates  to  the  PMs  use  of  time. 

8.1  TIME  MANAGEMENT  AND 
THE  PROGRAM 

This  section  concerns  three  aspects  of  time 
management  related  to  programs: 

(1)  Time  reserve 

(2)  "Now"  schedule 

(3)  Value  of  time. 

8.1.1  Time  Reserve 

In  contractor  performance  measurement, 
much  emphasis  is  placed  on  "management 
reserve,"  the  reserve  budget  controlled  by 
the  industry  PM.  What  isn't  always  recog¬ 
nized  is  that  a  time  reserve  is  also  needed  in 
order  to  accommodate  unknowns  in  the  pro¬ 
gram.  However,  use  of  a  time  reserve  should 
be  approached  with  caution,  because  mem¬ 
bers  of  a  program  office  team  maybe  tempted 
to  fall  back  on  it  prematurely. 

Literature  describing  time  reserve  is  scarce. 
However,  there  are  some  aspects  of  a  time 
reserve  that  are  clear. 


(1)  Most  PMs  establish  a  time  reserve  of 
about  10  percent.  On  a  40-month  program, 
for  example,  a  4-month  time  reserve  would 
be  established. 

(2)  The  time  reserve  must  be  held  closely 
by  the  PM.  Otherwise,  every  manager  on 
his  / her  program  may  think  "I  know  there's 
a  time  reserve ;  therefore,  I  don't  really  have 
to  meet  my  schedule."  The  PM  may  place 
this  reserve  under  "additional  system  tests" 
or  another  downstream  activity.  The  point 
is,  it  shouldn't  be  visible.  (A  built-in  safety 
factor  between  the  manufacturing  sched¬ 
ule  and  the  delivery  schedule  is  often  used. ) 

(3)  A  tough  and  disciplined  approach  to 
meeting  the  published  schedule  is  required 
from  the  start  of  a  program  in  order  to 
maintain  the  reserve  and,  consequently,  to 
meet  the  program  schedule  in  spite  of  slip¬ 
pages  caused  by  the  unknown  unknowns 
(unk-unks)  that  inevitably  arise. 

8.1.2  "Now"  Schedule 

There  is  a  direct  relationship  between  time 
and  cost  for  any  activity.  This  relationship 
takes  into  account  the  people,  resources, 
and  method  used.  It  also  considers  the 
efficiency  achieved.  Generally,  the  least 
costly  schedule  is  the  current  one.  Speed¬ 
ing  up  the  schedule  costs  more;  stretching 
out  the  schedule  also  costs  more. 

The  sum  of  the  direct  and  indirect  costs 
gives  a  U-shaped  total  program  cost  curve. 
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The  optimum  schedule  for  implementing 
the  program  is  the  schedule  correspond¬ 
ing  to  the  minimum  point  on  this  curve. 
The  relationship  among  direct,  indirect, 
and  total  program  cost  is  shown  graphi¬ 
cally  in  Figure  8-1. 

Because  schedule  stability  affects  program 
costs,  which  may,  in  turn,  affect  technical 
performance,  it  is  clear  that  schedule  sta¬ 
bility  has  a  great  deal  to  do  with  whether 
the  program  meets  its  cost  and  technical 
objectives.  Unfortunately,  budget  con¬ 
straints  and  other  factors,  like  changes  in 
quantities  (items  over  which  the  PM  has  no 
control),  have  often  been  imposed  on  a 
program  with  the  comment,  "Do  the  best 
you  can." 

When  a  schedule  must  be  revised,  the 
superseded  schedule  is  often  discarded.  If 
the  new  schedule  is  superseded,  the  pro¬ 
cess  is  repeated.  However,  there  is  some 
value  in  retaining  an  obsolete  schedule. 


Often,  the  organization  causing  a  slip  in 
schedule  becomes  a  repeat  offender.  The 
principal  value  of  retaining  a  former  sched¬ 
ule  lies  in  being  able  to  hold  the  offender's 
feet  to  the  fire,  thus  making  schedule 
slips  less  palatable. 

The  significance  of  maintaining  a  stable 
schedule  is  becoming  more  widely  recog¬ 
nized.  Appendix  A  describes  the  develop¬ 
ment  of  a  master  schedule  and  the  impor¬ 
tance  of  maintaining  schedule  discipline. 

8.1.3  Value  of  Time 

According  to  the  late  John  H.  Richardson, 
president  of  Hughes  Aircraft  Company, 
"A  basic  reason  for  adopting  project  (or 
program)  management,  when  tackling  the 
difficult  and  unique  tasks  associated  with 
developing  and  producing  a  system,  is  to 
eliminate  uimecessary  delays  in  accom¬ 
plishing  the  job  at  hand.  Time  is  a  resource 
in  systems  management,  to  be  treated  with 


Figure  8-1 .  Total  Cost  Analysis  for  Selecting 
“Optimum”  Program  Duration 
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indifference  or  used  well  like  any  other 
resource.  For  projects  not  yet  in  full  swing, 
it  is  important  to  recognize  that  time  has 
economic  value,  and  that  we  may  be  taking 
time  too  much  for  granted."^ 

(1)  Funding  could  create  a  problem.  In 
hungry  years,  the  schedule  is  often 
stretched  because  of  reduced  funding. 

(2)  A  better  product  could  be  developed 
if  it  were  more  thoroughly  debugged  and 
tested.  However,  a  system  does  not  really 
get  wrung-out  until  it  is  in  the  user's  hands, 
regardless  of  advance  debugging. 

(3)  Cost  of  concurrency  (overlap  of  devel¬ 
opment  and  production)  might  lead  to  a 
decision  not  to  overlap  program  phases. 
Such  a  decision  might  be  popular  in  many 
cases,  but  it  could  never  be  tolerated  when 
the  pendulum  swings  toward  the  impor¬ 
tance  of  time;  that  is,  when  top  manage¬ 
ment  says,  "Get  the  system  out  the  door, 
never  mind  what  it  costs. 

Stretched-out  schedules  incur  cost  penal¬ 
ties  because  of  inflation,  additional  engi¬ 
neering  changes,  and  changes  in  key  pro¬ 
gram  management  office  positions.  An¬ 
other  near-term  cost  is  due  to  the  increased 
chance  that  a  program  will  be  canceled 
because  of  obsolescence  or  competing  tech¬ 
nology.  Stretch-outs  invite  cancellation. 
Also,  long  schedules  with  no  opportuni¬ 
ties  for  incorporation  of  improvements  are 
a  negative  factor  when  considering  a  new 
start. 

Delayed  decisions  increase  costs.  Accord¬ 
ing  to  R.  W.  Peterson,  former  DuPont  execu¬ 
tive,  "All  businessmen  are  concerned,  and 
properly  so,  about  the  long  time  it  takes  to 
move  a  new  development  from  its  incep¬ 
tion  to  a  profit  status.  But  frequently 


forgotten  is  the  fact  that  a  month's  delay  in  the 
early  stages  of  development  is  exactly  as 
long  as  a  month's  delay  in  the  later  stages. 
While  it  may  seem  innocuous  to  put  off  a 
decision  for  a  month  or  two  in  the  early  years 
of  a  project  (or  program)  with  an  uncertain 
future,  that  delay  may  turn  out  to  be  just  as 
costly  as  is  procrastination  when  the  final 
decisions  are  made.  In  short,  a  sense  of  ur¬ 
gency  is  essential  to  decision  making  in  all 
stages  of  a  new  venture,  not  just  the  later 
stages."^ 

The  useful  Hfe  of  a  defense  system  must  be 
taken  into  consideration.  Concentration  on 
the  system  or  product  often  overlooks  a  key 
point:  whether  the  buyer  obtains  value  upon 
delivery.  The  most  costly  product  is  one  that 
appears  when  it  no  longer  fulfills  a  useful 
purpose,  even  though  it  has  been  produced 
at  minimum  cost.  Each  month  added  to  the 
development  and  production  of  a  new  high- 
technology  system  or  product  tends  to  re¬ 
duce  by  1  month  the  operational  life  of  the 
system  or  product. 

In  spite  of  the  10-20  percent  cost  premium 
that  may  be  paid  for  tight  scheduling  (as 
compared  to  orderly  but  stretched-out  sched¬ 
uling),  the  resulting  longer  operational  life 
may  provide  greater  economic  value.  This  is 
looking  at  time  only  from  the  viewpoint  of 
economics,  i.e.,  acquisition  cost  per  year  of 
operational  availabil  survival  insurance. 

Consideration  of  alternative  plans  and  sched¬ 
ules  will  also  help;  e.g.,  if  event  so-and-so 
occurs,  proceed  with  plan  A;  if  event  such- 
and-such  occurs,  proceed  with  plan  B  and  so 
on.  Anticipation  and  preparation  for  most- 
likely  events,  along  with  the  tools  described, 
and  coupled  with  effective  communication 
of  the  plans,  can  change  the  management 
style  from  crisis  management  to  skillful 
management. 
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8.2  TIME  MANAGEMENT  AND  THE 
PROGRAM  MANAGERS 

PMs  are  busy  people.  They  have  the  re¬ 
sponsibility  for  the  management  of  a 
myriad  of  activities  and  the  resources  that 
make  up  the  program.  In  addition,  they  are 
often  required  to  perform  specific  program 
activities,  especially  in  smaller  programs. 
Thus,  it  is  important  that  they  manage  their 
time  well.  Some  managers  could  be  more 
productive,  perhaps  as  much  as  20-40  per¬ 
cent,  by  better  managing  their  time.  A  ma¬ 
jor  difficulty  in  accomplishing  this  is  the 
failure  to  realize  that  there  is  a  time  man¬ 
agement  problem  and  that  solutions  are 
possible.  This  section  discusses  various 
aspects  of  time  management  and  identifies 
ways  to  better  accomplish  it. 

In  the  early  1980s,  a  time  management  sur¬ 
vey  was  conducted  to  identify  the  prob¬ 
lems  in  achieving  effective  time  manage¬ 
ment.  More  than  300  project  managers  in  24 
industries,  including  the  government,  par¬ 
ticipated  in  the  survey,  which  investigated 
15  different  areas.  The  survey  identified 
several  time  management  problem  areas. 
Among  the  most  common  were  time  rob¬ 
bers  and  meetings. 

Time  robbers  are  simply  those  things  that 
can  occur  on  a  day-to-day  basis  that  can 
take  away  from  the  PMs  ability  and  time  to 
accomplish  his/her  work.  There  are  liter¬ 
ally  dozens,  if  not  hundreds,  of  such  things, 
such  as  incomplete  work,  delayed  deci¬ 
sions,  poor  communications  chaimels,  ca¬ 
sual  visitors,  lack  of  effective  program 
management  tools,  etc.  Appendix  B  con¬ 
tains  a  list  of  common  time  robbers.  The 
survey  found  that  delayed  decisions  and 
poor  communications  were  the  most  com¬ 
monly  cited  time  robbers.  Another  com¬ 
mon  problem  that  affects  a  PMs  time  is  the 


inability  or  reluctance  to  say  no.  If  a  subor¬ 
dinate  brings  a  problem  to  the  PM,  the 
Manager  must  be  alert  to  make  sure  not  to 
assume  responsibility  for  the  problem, 
unless,  of  course,  the  situation  warrants 
such  action.  If  subordinates  believe  that 
PMs  will  assume  responsibility  for  their 
problems,  needless  demands  on  the  PM's 
time  will  increase. 

Meetings  are  a  fact  of  life  in  program  man¬ 
agement.  However,  unless  they  are  effec¬ 
tively  plaimed  and  conducted,  they  can  be 
a  severe  drain  on  time  and  resources.  A 
number  of  common  pitfalls,  if  not  avoided, 
can  turn  meetings  into  a  complete  waste  of 
time.  Among  them  are:  not  having  a  clear 
and  focused  agenda;  spending  too  much 
time  on  trivial  matters;  having  too  many  or 
too  few  meetings;  not  having  the  right 
people  at  the  meetings;  and  not  keeping  an 
accurate  record  of  decisions  and  actions 
assigned. 

To  get  the  most  value  out  of  meetings,  the 
following  actions  should  be  considered: 

(1 )  Understand  the  purpose  of  the  meeting 
and  what  results  are  expected 

(2)  Minimize  the  number  of  people  attend¬ 
ing  the  meeting 

(3)  Hold  the  meeting  in  a  setting  appro¬ 
priate  for  the  meeting  objectives 

(4)  Develop  and  distribute  the  agenda 

(5)  Start  and  finish  on  time 

(6)  Summarize  meeting  results  and  pre¬ 
pare  and  distribute  minutes. 

In  addition  to  focusing  on  time  robbers 
and  the  conduct  of  meetings,  PMs  should 
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also  concentrate  on  other  effective  time 
management  techniques,  such  as: 

(7)  Prioritize  activities 

(8)  Devote  solid  time  blocks  for  important 
activities 

(9)  Maintain  "to  do"  lists  and  time  logs 

(10)  Delegate 

(11)  Manage  by  exception 

(12)  Practice  calculated  neglect 

(13)  Control  access — limit  casual  visits 
and  telephone  calls. 

8.3  SUMMARY 

Planning  and  scheduling  can  do  much  to 
prevent  running  out  of  time  and  having  to 


make  the  least  desirable  decision  because 
of  lack  of  time.  Establishing  a  time  reserve 
and  a  "now"  schedule,  and  recognizing  the 
value  of  time  in  decision  making  all  con¬ 
tribute  to  the  PMs  repertoire  of  good  tools. 

Sir  Jeffrey  Quill,  manager  of  the  British 
Spitfire  Development  Program,  com¬ 
mented  during  a  visit  to  DSMC  that;  "After 
1935,  costs  weren't  particularly  important. 
What  mattered  was  time.  We  worked  three 
shifts  a  day.  Everything  was  time.  Quan¬ 
tity  and  time.  It  turned  out  that  we  prob¬ 
ably  produced  at  the  lowest  cost,  too;  but 
the  emphasis  was  on  time." 

PMs  must  manage  their  time  effectively  if 
they  are  to  be  successful.  They  must  be 
alert  to  those  time  robbers  that  affect  their 
ability  to  accomplish  their  work  and  un¬ 
derstand  the  value  of  proven  time  manage¬ 
ment  techniques. 
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9 

AUTOMATED  SCHEDULING  TOOLS 


Previous  chapters  have  shown  that  manag¬ 
ers  use  schedules  in  a  variety  of  ways  for  a 
wide  range  of  purposes.  Schedules  are  an 
integral  part  of  the  program  plaiming  and 
decision  processes.  Managers  use  them  to 
track  progress,  predict  future  work,  man¬ 
age  resources,  analyze  alternatives,  iden¬ 
tify  risk,  and  report  program  status.  In 
most  cases,  it  is  the  PMs  responsibility  to 
construct,  revise,  maintain,  and  report 
schedule  information. 

The  PM  must  do  these  things  in  a  complex 
environment  that  cuts  across  contractor  and 
government  boundaries  and  includes  a 
wide  geographical  area.  The  challenge  is 
complicated  even  further  by  the  need  for 
instant  information  that  must  be  available 
to  a  wide  audience  that  usually  requires 
the  information  in  a  specific  format  to  suit 
unique  needs. 

It  would  be  impossible  to  meet  these  chal¬ 
lenges  without  automated  tools. The 
remainder  of  this  chapter  discusses  charac¬ 
teristics  and  features  of  some  tools  avail¬ 
able  on  the  market  today  and  suggests 
criteria  that  anyone  searching  for  a  tool 
should  consider.  The  intent  is  to  provide 
an  overview  of  the  types  of  products  that 
are  available  and  the  range  of  functions 
these  products  support.  The  level  of  detail 
presented  is  keyed  to  what  would  be  use¬ 
ful  to  know  about  the  program  manage¬ 
ment  software  tools  that  would  likely  be 
used  in  a  mid-to-large  Program  Office. 


9.1  AUTOMATED  PLANNING  AIDS 

The  idea  to  use  the  power  of  the  computer 
to  assist  in  the  plaiming  and  tracking  pro¬ 
cess  is  not  new.  Industry  has  used  auto¬ 
mated  scheduling  software  for  at  least  the 
past  30  years.  Early  versions  of  these  tools, 
however,  usually  employed  a  mainframe 
computer  that  batch  processed  data  off¬ 
line  and  spewed  reams  of  information  for 
managers  to  analyze  when  they  arrived  at 
work  on  a  Monday  morning.  Despite  the 
automated  tools,  the  process  of  creating, 
maintaining,  and  reporting  schedule  infor¬ 
mation  was  a  daunting  task. 

The  advent  of  PCs/ workstations  and  net¬ 
work  technologies  has  made  life  easier  for 
managers.  The  market  encourages  soft¬ 
ware  vendors  to  develop  a  wide  range  of 
programs  readily  available  to  P  Ms  to  aid 
them  in  effectively  and  efficiently  dealing 
with  the  details  involved  in  creating  a  pro¬ 
gram  plan,  then  tracking  progress. 

The  introductory  paragraph  of  this  chap¬ 
ter  lists  many  uses  of  a  "schedule."  Soft¬ 
ware  developers  have  responded  to  the 
managers'  needs  by  creating  programs 
that  build  schedules  and  support  pro¬ 
gram  management  functions.  Even  the 
simplest  program  includes  some  program 
management  features.  The  focus  of  the 
following  discussion,  therefore,  is  on  the 
broad  category  of  Program  (often  called 
Project)  Management  Software. 
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The  focus  is  on  providing  a  brief  descrip¬ 
tion  of  the  functionality  of  these  products, 
highlighting  some  of  the  desir  able  features 
that  are  available  to  support  program 
management,  and  identifying  sources  that 
may  be  useful  in  determining  what  prod¬ 
ucts  are  available  and  how  their  features 
and  performance  might  be  assessed. 

9.2  FUNCTIONAL  CHARACTERISTICS 

AND  FEATURES 

Most  of  the  Program  Management  Soft¬ 
ware  that  is  available  today  is  based  on  a 
relational  database  design  and  is  therefore 
able  to  support  a  broad  range  of  program 
management  activities  including: 

(1)  Scheduling/Tracking 

(2)  Resource  Plaiming/Management 

(3)  Risk  Management 

(4)  Cost/Performance/Analysis 

(5)  Reports  and  Graphics. 

The  extent  to  which  the  different  programs 
support  these  activities  varies  from  prod¬ 
uct  to  product.  For  example,  some  prod¬ 
ucts  provide  the  capability  to  create  only 
Gantt  charts  whereas  others  provide  the 
tools  to  make  Gantt  and  network  charts. 

Program  features,  the  way  in  which  activi¬ 
ties  are  implemented,  are  an  important 
factor  in  considering  the  usefulness  of  a 
program.  A  convenient  way  to  profile  the 
functional  characteristics  and  associated 
features  of  automated  program  manage¬ 
ment  tools  is  to  do  so  from  these  three 
perspectives: 


(1)  System-Level  Gharacteristics 

(2)  Project  Management/Scheduling 
Gharacteristics 

(3)  Ease  of  Use. 

System-level  features  have  a  general 
applicability,  independent  of  any  of  the 
specific  project-management  activities  sup¬ 
ported,  that  add  to  the  overall  capability 
and  desirability  of  the  product.  These  fea¬ 
tures  include,  but  may  not  be  limited  to: 

•  Collaboration/Workgroup — Enables 
managers /team  members  to  use  a  com¬ 
mon  system  of  communication  and  allow 
access  to  common  databases  for  the  pur¬ 
pose  of  assigning  tasks,  updating  project 
data,  assigning  resources,  and  reporting 
status. 

•  Integral  e-mail — Allows  exchange  of 
messages  and  file  attachments  to  other 
project  team  members  from  within  the 
project  management  application. 

•  Multiple  Pro]  ect/Multiple  T asks — Sup¬ 
ports  multiple  programs  and  tasks  within 
a  project. 

•  Security — Limits  access  to  certain  data 
by  individual  or  class  of  user,  as  well  as 
password  protection  for  the  system. 

•  Open  Data  Base  Connectivity 
(ODBC) — Enables  users  to  import  data 
from  other  data  sources  and  in  various 
formats  into  their  scheduling  applications 
(e.g.,  data  from  your  contractor's  project 
database).  This  is  a  Microsoft-developed 
standard  for  exchanging  data  with  a  vari¬ 
ety  of  databases. 
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Most  programs  include  features  that  focus 
on  program  management  and  schedule 
functions.  Some  features  offered  are: 

•  Project  Scheduling/Tracking — Data 
Entry  Templates  facilitate  the  entry  of  the 
initial  task,  time,  and  resource  data.  On- 
Screen  Tracking  facilitates  comparison  of 
actual  performance  versus  the  plaimed  and 
allows  tracking  of  progress  by  cost,  time, 
or  achievement. 

•  Resource  Planning/Management — Re¬ 
source  Leveling  is  a  capability  that  resolves 
resource  conflicts  by  delaying  tasks  and 
assignments  as  well  as  by  task  splitting, 
which  entails  dividing  tasks  into  segments 
with  time  gaps  as  necessary.  Resource  Cal¬ 
endars  provide  insight  into  the  availability 
of  a  particular  resource  by  showing  work¬ 
ing  and  non-working  times.  Free/Total  S lack 
Time  is  a  feature  that  is  useful  for  adjusting 
under-or-over  allocated  resources. 

•  Cost/Performance  Analysis — Earned 
Value  Tools  are  essential  for  comparing  ac¬ 
tual  performance  with  expected  perform¬ 
ance.  Cost  Analysis  Tool  Kits  are  tools  for 
analyzing  data  and  making  forecasts.  This 
feature  may  be  integral  to  the  product  or 
available  by  virtue  of  "exporting"  data  to 
another  application  with  this  capability. 

•  Reports  and  Graphics — Pre-Defined Re¬ 
ports  facilitate  the  presentation  of  project 
data.  Customization  Controls  provide  users 
with  a  convenient  way  to  format  reports  to 
their  own  specifications.  Filters  enable  the 
user  to  screen  information,  e.g.,  tasks  or 
resources,  before  capturing  a  screen-view 
or  preparing  a  report.  Embedded  Graphics 
and  Text  capability  allows  a  user  to  import 
data  from  other  applications  for  inclusion 
in  a  project  report. 


•  Import/Export — Import/Export  data 
from /to  an  external  source,  such  as  an¬ 
other  database  or  spread  sheets,  facilitates 
the  ability  to  create  custom  reports  or  con¬ 
duct  analyses. 

Finally,  ease  of  use  or  user  friendliness,  is 
the  set  of  qualities  that  represent  the  de¬ 
gree  in  which  people  can  employ  the  soft¬ 
ware  without  an  inordinate  amount  of  train¬ 
ing  or  regular  reference  to  user's  manuals. 
User  friendliness  is  an  important  consider¬ 
ation  because  program  management  soft¬ 
ware  products  can  be  complicated.  Re¬ 
gardless  of  how  powerful  a  program  may 
be,  if  it  is  difficult  to  use,  managers  prob¬ 
ably  will  not  spend  the  time  to  learn  it. 
Consequently,  PM  software  is  likely  to  be 
effective  and  desirable  if  users  can  easily 
learn  to  use  it. 

The  following  features  typify  user-friendly 
systems: 

•  Graphical  User  Interfaces  (GUIs) — 

These  are  the  screens  in  which  a  user  inter¬ 
acts  with  the  program.  The  operating  envi¬ 
ronments  in  use  today  have  led  to  the 
development  of  interface  screens  that  en¬ 
able  the  user  to  interact  with  the  software  in 
an  intuitive  way,  using  a  variety  of  but¬ 
tons,  menu  lists,  and  wizards. 

•  On-Screen  Data  Entry — The  capability 
to  create  schedule  information  by  using 
tools  to  create  an  on-screen  graph.  See  Fig¬ 
ure  9-1  for  an  example. 

•  Help  Function — On-screen  docu¬ 
mentation  as  well  as  "context-sensitive" 
help  in  which  the  software  displays  the 
applicable  text  based  on  the  functions  be¬ 
ing  performed.  This  is  a  particularly  useful 
feature  for  someone  learning  to  use  it. 


67 


Figure  9-1.  On  -Screen  Data  Entry  Using  Gantt  Chart  Feature 
(AEC  Software  Fast  Track  Scheduie) 


•  Tutorials — Program  instruction  on  per-  9.3  EVALUATING  PROJECT 

forming  certain  functions  and  guidance  MANAGEMENT  SOFTWARE 

through  a  "caimed"  demonstration.  PRODUCTS 

•  Wizards — Templates  that  guide  the  Choosing  a  software  program  from  the 

user  through  various  project  setup,  data  wide  range  of  available  products  can  be 
entry,  and  report  formatting  procedures.  complex  and  time  consuming.  The  selec- 
The  features  discussed  above  are  a  sample  tion  process  should  begin  with  an  analysis 
of  the  characteristics  of  various  program  of  what  managers  want  to  do  with  the 

management  products.  Moreover,  there  is  software  to  identify  the  functions  that  are 

no  common  "feature  list"  or  set  of  defini-  needed.  Other  factors  that  should  be  part 

tions  that  defines  the  various  characteris-  of  the  assessment  process  are  consider- 

tics.  N onetheless,  the  summary  should  give  ation  of  persormel  skill  levels  /  training  re- 

a  sense  of  what  is  available  and  provide  the  quirements,  integration  with  enterprise 

basis  for  a  more  exhaustive  review  as  (organizational)  systems,  hardware /sys- 

needed.  tern  requirements,  and  cost. 
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Table  9-1.  Project  Management  Software  Functions  and  Criteria 


USER  FRIENDLINESS 

Feature 

Consideration 

Graphical  User  Interfaces  (GUIs) 

Logical,  intuitive,  all  inclusive,  windews  compliant 

Robust  Help  Function 

Complete,  easy  te  access,  context  based,  examples 

Wizards 

Exist  for  major  functional  areas,  intuitive,  tailerable  results 

Tools 

Exist  for  major  functional  areas,  intuitive 

Tutorials 

Complete  and  examples 

On-Screen  Data  Entry 

Simple,  logical,  complete,  intuitive 

SYSTEM  LEVEL  FEATURES 

Collaboration/Workgroup  Support 

Desired  capabilities  available,  non-proprietary 

Integral  e-mail 

Exists,  simple,  compatibility  with  existing  e-mail 

Multi-Project  &  Task  Support 

Roll-up  to  higher  levels,  supported  by  reporting  features 

Security 

Meets  specific  security  needs,  compatible  w/  existing  system 

Open  Data  Base  Connectivity 

Data  transfer  with  other  pregram  management  SA/V 

PROJECT  MANAGEMENT/SCHEDULING  FUNCTIONS 

Project  Scheduling/Tracking 

Multiple  Schedule  Methods 

Create  Gantt,  netwerk  charts,  and  go  from  one  to  the  other 

Roll-Up 

Display  and  report  different  levels 

Ability  to  Tailor  to  Specific  Needs 

Add/delete/modify  activity  and  event  information 

Relationships 

Display  and  report  dependencies  among  events/activities 

Progress  Tracking 

Compare  and  display  plans  and  actual  progress 

Critical  Path  Display 

Highlight  critical  path 

Interoperability  w/  Other  Programs 

Import  and  export  data  from  other  programs 

Total  Free/Slack  Time 

Compute  and  display  free  and  slack  time 

Time  Estimates 

Use  probability  distributions  to  compute  time  to  complete 

Time  Roll-Up 

Use  statistical  methods  to  compute  roll-up  times 

Resource  Planning/Management 

Resource  Determination 

Assist  in  determining  resources  needed 

Resource  Assignment 

Allow  assignment  and  netification  of  assignment  to  activities 

Interoperability  w/  Other  Pregrams 

Impert  and  expert  reseurce  data 

Resource  Leveling 

Easy  to  access,  permits  ‘‘what  if”  excursions 

Resource  Calendars 

Display  resources  over  time 

Task  Assignment 

Filter  and  display  assignment  of  responsibility 

Analysis 

Schedule  Analysis 

Allow  analysis  and  comparison  of  alternative  schedules 

Earned  Value  Analysis 

Assist  in  cemplete  and  accurate  EV  analysis 

Cost  Analysis 

Includes  teol  kits  for  analysis  of  program  cost 

Resource  Analysis 

Compute  resource  utilizatien,  identify  conflicts 

Reports 

Pre-Defined  Report  Formats 

Automatically  create  reperts  based  on  program  data 

Customization  Controls 

Allow  reports  to  be  tailored  fer  specific  purposes 

Embedded  Graphics  and  Text 

Add  text  and  graphics  to  reports 
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Analyses  of  requirements  and  software 
evaluation  are  beyond  the  scope  of  this 
discussion.  However,  Table  9-1  shows 
some  of  the  functions  that  are  available  in 
available  program  management  software 
and  lists  some  ideas  for  consideration  when 
searching  for  the  right  software. 

9.4  FINDING  OUT  MORE 

The  best  method  of  gaining  information 
about  a  potential  project  management  tool 
is  to  talk  to  someone  who  is  using  the 
product.  A  PM  in  the  next  office  may  have 
a  perfectly  acceptable  and  proven  product 
that  he/ she  is  using.  The  company  under 
contract  may  have  a  product  that  it  uses.  If 
the  government  and  contractor  program 


offices  are  going  to  share  information,  it  is 
prudent  to  use  the  same  software,  if  pos¬ 
sible.  At  the  very  least,  compatibility  and 
interoperability  must  be  demonstrated  be¬ 
fore  making  a  decision  to  buy  a  particular 
product. 

There  is  a  considerable  information  on 
project  management  and  scheduling  soft¬ 
ware  from  a  variety  of  sources.  The  Defense 
Acquisition  Deskbook  (DAD)  has  a  list  of  tools 
that  are  being  used  by  program  offices. 
From  a  commercial  aspect,  specific  prod¬ 
uct  information  is  available  on  most  com¬ 
panies'  World  Wide  Web  home  pages. 
Virtually  all  developers  provide  informa¬ 
tion  about  their  products  on  a  web  site  and 
show  links /contact  to  additional  sources. 
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APPENDIX  A 


INTEGRATED  MASTER  SCHEDULE  DESCRIPTION 


The  Integrated  Master  Schedule  (IMS)  for  a 
program  should  be  a  time  reference 
baseline  for  the  activities  and  events  that 
make  up  the  program.  It  should  be  incor¬ 
porated  into  the  program  plan  and  linked 
to  approved  performance  and  cost  objec¬ 
tives.  The  IMS  is  developed  by  the  contrac¬ 
tor  from  the  Integrated  Master  Plan  (IMP), 
which  documents  all  the  tasks  required  to 
deliver  a  high  quality  product  and  to  facili¬ 
tate  success  throughout  the  product's  life 
cycle.  In  an  Integrated  Product  and  Process 
Development  (IPPD)  environment,  which 
is  the  standard  approach  for  all  DoD  pro¬ 
grams,  the  IMP  and  IMS  provide  an 
overarching  framework  against  which  the 
Integrated  Product  Teams  (IPTs)  can  func¬ 
tion,  helping  them  understand  their  work 
within  the  context  of  the  total  program. 

The  IMP  and  IMS  evolve  as  the  program 
matures.  During  the  initial  stages  of  Con¬ 
cept  Exploration,  the  integrated  plan  is 
preliminary  and  its  purpose  is  to  provide 
an  understanding  of  the  scope  of  work 
required  and  the  likely  structure  of  the 
program.  It  is  constructed  to  depict  a  likely 
progression  of  work  through  the  remain¬ 
ing  phases,  with  the  most  emphasis  on  the 
current  and  /  or  upcoming  phase  (especially 
the  period  to  be  contracted  for  next) .  As  the 
program  is  defined,  the  IMP  is  iterated 
several  times,  each  time  increasing  the  level 
of  detail  and  confidence  at  which  all  essen¬ 
tial  work  has  been  identified.  The  specific 
format  for  this  plan  is  not  critical;  however, 
it  usually  reflects  an  Event /Accomplish¬ 
ment /Criteria  hierarchical  structure — a 


format  that  greatly  facilitates  the  tracking 
and  execution  of  the  program. 

In  some  cases,  a  preliminary  IMP  and  its 
corresponding  IMS  may  be  developed  by 
the  government  but  include  industry  in¬ 
puts  obtained  through  open  communica¬ 
tions  with  potential  sources  during  the 
pre-solicitation  phase  of  the  acquisition. 
Contractors  are  normally  required  to  sub¬ 
mit  formal  IMP  and  IMS  with  their  propos¬ 
als  and  to  develop  more  detailed  IMP/ 
IMS  versions  after  the  contract  is  awarded. 

The  IMS  is  event  driven  and  is  developed 
with  participation  of  all  program  stake¬ 
holders.  It  should  identify  all  tasks  that 
need  to  be  accomplished,  their  logical  or¬ 
der,  and  the  input  conditions  necessary  to 
complete  each  task.  When  documented  in 
a  formal  plan  and  schedule,  this  event- 
driven  approach  can  help  ensure  that  all 
tasks  are  integrated  properly  and  that  the 
management  process  is  based  on  signifi¬ 
cant  events  in  the  acquisition  life  cycle  and 
not  on  arbitrary  calendar  events.  Develop¬ 
ing  the  program  schedule  presents  an  op¬ 
portunity  to  identify  critical  risk  areas.  As 
IPT  members  estimate  the  times  to  com¬ 
plete  specific  tasks,  events  that  may  cause 
delays  willbecome  apparent.  These  events 
are  potential  areas  of  risk  that  the  IPT 
should  consider  for  further  analysis. 

The  IMS  begins  as  an  IMP  with  dates — the 
starting  points  are  the  events,  accomplish¬ 
ments,  and  criteria  that  make  up  the  plan. 
At  a  minimum,  an  IMS  shows  the  expected 
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start  and  stop  dates  for  each  activity  in  the 
plan,  but  each  activity  may  be  broken  down 
into  lower-level  tasks  that  will  be  used  to 
manage  the  program  on  a  day-to-day  ba¬ 
sis.  The  schedule  can  be  expanded  down¬ 
ward  to  the  level  of  detail  appropriate  for 
the  scope  and  risk  of  the  program.  Pro¬ 
grams  with  high  risk  show  much  lower 
levels  of  detail  in  the  integrated  master 
schedule  in  order  to  give  the  visibility 
necessary  to  manage  risk.  The  more  de¬ 
tailed  the  IMS,  however,  the  greater  the 
cost  to  track  and  update  the  schedule. 
Under  acquisition  reform  initiatives,  the 
dates  in  the  IMS  usually  are  not  made 
contractually  binding  so  as  to  allow  the 
flexibility  to  take  full  advantage  of  event- 
driven  scheduling. 

Additional  information  on  the  development 
of  IMSs  can  be  found  in  various  sections  of 
the  Defense  Acquisition  Deskbook  and  in  the 
DoD  Integrated  Product  and  Process  Develop¬ 
ment  Handbook  dated  August  1998.  Com¬ 
mercial  standards  El  A  632  and  IEEE  1220- 
1994  can  also  be  consulted  for  more  infor¬ 
mation  on  developing  master  plans  and 
schedules.  See  http:  /  / www.eia.org / eng / 
published. htma  n  d  http:/  / 
standards.ieee.org  for  information  on 
how  to  obtain  these  standards.  A  DoD 
Data  Item  Descriptor  (DI-MISC-81 183 A) 
has  been  developed  for  IMS  guidance; 
it  is  attached  to  this  Appendix  as  Tab  1. 

USE  OF  INTEGRATED  MASTER 
SCHEDULES 

The  primary  purpose  of  the  IMS  is  to  track 
schedule  variations.  By  linking  the  IMS  to 
the  IMP,  it  can  also  be  used  to  track  the 
activities  that  provide  functional  and  life- 
cycle  inputs  to  product  development.  In 
this  role  it  provides  a  crosscheck  not  only 
that  the  inputs  were  obtained,  but  also  that 


they  were  obtained  at  the  right  time.  In 
addition,  the  IMS  can  be  useful  for  the 
following  events/activities  that  are  com¬ 
mon  to  all  programs. 

PROGRAM  REVIEWS 

The  IMS  can  be  a  framework  for  periodic 
program  reviews  within  the  program  man¬ 
agement  office  (PMO).  If  constructed  prop¬ 
erly,  the  schedule  will  illustrate  the  vari¬ 
ous  levels  of  the  program  and  will  be  com¬ 
patible  with  the  program  cost/schedule 
control  system  reports. 

Program  reviews  can  be  an  excellent  forum 
for  resolution  of  schedule  conflicts  and  the 
genesis  for  controlled  changes  to  the  sched¬ 
ule  from  within  the  PMO.  Most  key  mem¬ 
bers  of  the  PMO  team  are  present  at  these 
reviews;  therefore,  proposed  schedule 
changes  or  slips  can  receive  wide  dissemi¬ 
nation  within  the  organization. 

WHAT  IF"  EXERCISES 

The  IMS  can  serve  as  the  framework  for 
"what  if"  exercises  imposed  on  programs 
from  outside  the  PMO.  Schedule  changes 
can  be  plotted  manually  by  using  over¬ 
lays.  Using  the  same  grid  coordinates  on 
an  overlay  allows  the  PMO  team  to  see, 
clearly  and  graphically,  the  effect  of  the 
compressions  or  extensions  of  sub-mile- 
stones  on  the  program.  It  may  be  even 
easier  (and  more  productive)  for  the  PMO 
team  to  run  "what  if"  exercises  on  a  com¬ 
puterized  schedule.  Without  a  master 
schedule  as  a  baseline,  these  exercises  can 
take  longer  to  accomplish  and  they  may 
overlook  important  variances  from  the 
program's  established  baseline  schedule 
or  plan. 
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PROGRAM  BRIEFINGS 

The  IMS  can  serve  as  a  baseline  for  pro¬ 
gram  reviews  at  higher  headquarters  and 
other  reviews  or  briefings  outside  the  PMO. 
Most  programs  have  key  milestones  taken 
from  the  master  schedule  and  presented  in 
summary  form  on  view  graphs  or  slides.  If 
these  do  not  show  the  detail  required  to 
make  a  point,  the  time  span  shown  can  be 
reduced  to  the  point  where  the  details 
become  visible. 

SCHEDULE  DISCIPLINE 

To  be  effective,  an  IMS  must  be  kept  up- 
to-date  and  accurate.  Maintenance  of  the 
IMS  requires  a  process  similar  to  that 
inherent  in  configuration  control — one 
that  establishes  discipline  through  a  set  of 
rigorous  procedures  for  managing  sched¬ 
ule  change.  The  degree  of  schedule  disci¬ 
pline  imposed  within  the  PMO  can  be  a 
major  factor  in  the  success  of  a  program. 
The  underlying  philosophy  of  the  sched¬ 
ule  control  process  should  reflect  central¬ 
ized  control  of  the  IMS.  That  is,  changes  to 
the  IMS  baseline  should  be  made  only 
with  the  approval  of  the  P2M  or  his/her 
designated  representative  and  with  full 


justification  and  an  understanding  of  the 
impact  of  the  changes  on  the  overall  pro¬ 
gram.  Following  are  examples  of  some 
simple  procedures  that,  if  practiced,  will 
instill  discipline  and  prevent  the  unautho¬ 
rized  release  of  schedule  information  that 
has  not  been  approved  for  inclusion  in  the 
IMS. 

•  Program  changes,  whatever  the  source, 
should  start  as  proposals  and,  if  approved, 
grow  into  a  firm  plan.  Eventually,  they  are 
incorporated  into  the  IMS  as  changes.  The 
question  of  when  to  plot  these  changes  is  a 
matter  of  judgment  and  should  reflect  the 
PM's  policy.  Each  change  should  be  plot¬ 
ted  as  a  proposed  or  tentative  change  until 
approved. 

•  A  permanent  record  of  each  change 
should  be  maintained.  If  the  program 
schedule  slips,  it  should  be  documented 
until  documentation  no  longer  serves  a 
useful  purpose. 

•  Whenever  copies  of  the  IMS  are  made, 
they  should  be  dated  and  authenticated  by 
the  signature  of  the  PM  or  the  appointed 
schedule  manager.  Undated  and  unauthen¬ 
ticated  schedules  should  not  be  released 
outside  the  PMO. 
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10.2.5  Periodic  analysis.  A  brief  summary  which  identifies  progress  to  date,  variances  to  the  planned 
schedule,  causes  for  the  variance,  potential  impacts  and  recommended  corrective  action  to  avoid 
schedule  delays.  For  each  program  milestone  planned,  forecasted  and  actual  completion  dates  shall  be 
reported.  The  analysis  shall  also  identify  potential  problems  and  a  continuing  assessment  of  the  network 
critical  path.  Thresholds  for  impact  reporting  shall  be  identified  on  the  DD  Form  1423,  CDRL. 

10.2.6  Integrated  program  network.  Logical  diagram  of  all  activities  in  the  program.  The  key  elements  of 
the  integrated  network  to  be  constructed  in  the  diagram  are  as  follows: 

a.  Milestone  or  event  -  A  specific  definable  accomplishment  in  the  program/project  network,  recognizable 
at  a  particular  point  in  time.  Milestones  are  numbered  and  may  be  contained  within  an  activity  box. 

b.  Activity  or  task  -  A  time  consuming  element,  e.g.  work  in  progress  between  interdependent  events, 
represented  by  an  activity  box. 

c.  Duration  -  Planned  length  of  time  needed  to  accomplish  an  event/activity. 

d.  Relationships  -  A  line  that  defines  how  two  activities  or  events  are  logically  linked.  It  can  take  up  to 
four  (4)  forms: 


(1)  FS  (finish  to  start)  -  An  activity  must  finish  before  another  can  start. 

(2)  SS  (start  to  start)  -  An  activity  depends  on  the  start  of  another 

activity. 

(3)  FF  (finish  to  finish)  -  One  activity  cannot  finish  until  another  activity 

is  finished. 

(4)  SF  (start  to  finish)  -  An  activity  cannot  finish  until  another  activity 

starts. 

e.  Slack  or  Float  -  Extra  time  available  on  an  activity  before  it  will  impact  an  activity  on  the  critical  path. 

f.  Lag  -  The  delay  or  wait  period  between  two  tasks. 

g.  Critical  Path  -  A  sequence  of  activities  in  the  network  that  has  the  longest  total  duration  through  the 
program  or  project.  Activities  along  the  critical  path  have  zero  or  negative  slack/float.  It  should  be  easily 
distinguished  on  the  report  formats,  e.g.  a  thick  line,  patterned  or  in  red  ink.  This  should  be  calculated  by 
computer-based  software. 

h.  Target  Start  (TS)  -  A  program  defined  date  of  when  an  activity  should  start.  This  is  an  operator- 
defined  date  rather  than  a  computer-calculated  date. 

i.  Target  Complete  (TC)  -  A  program  defined  date  of  when  an  activity  should  finish.  This  is  an  operator- 
defined  date  rather  than  a  computer-calculated  date. 

j.  Actual  Start  (AS)  -  Actual  start  date  of  an  activity. 

k.  Actual  Finish  (AF)  -  Actual  finish  date  of  an  activity. 

l.  Early  Start  (ES)  -  The  earliest  start  date  an  activity  can  begin  the  precedence  relationships.  Computer- 
calculated  date. 

m.  Early  Finish  (EF)  -  The  earliest  finish  date  an  activity  can  end.  Computer-calculated  date. 

n.  Late  Start  (LS)  -  The  latest  start  date  an  activity  can  start  without  delaying  the  program  or  project 
target  completion  date.  Computer-calculated  date. 
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o.  Late  Finish  (LF)  -  The  latest  finish  date  an  activity  can  have  without  affecting  the 
program  or  project  target  completion  date.  Computer-calculated  date. 

p.  Percent  Complete  (PC)  -  Actual  progress  of  an  activity  from  its  start  to  its  finish. 

10.3  Master  Integrated  Program  Schedule.  It  shall  display  all  of  the  proposed 
activities,  events,  and  milestones  from  contract  award  to  the  completion  of  the  contract. 

10.4  Descriptive  titles.  Activities,  tasks,  events,  and  milestones  shall  be  labeled  with 
a  brief  descriptive  title,  numbered  of  coded  and  contain  time  constraints  (e.g.  duration, 
TS,  ES,  EF,  LS,  LF,  etc.).  Standard  abbreviations  may  be  used  to  conserve  space. 
Descriptive  titles  used  on  activities,  events,  and  milestones  shall  be  identical  on  all 
program  schedules.  A  legend  shall  be  provided  to  aid  in  ease  of  reading  the  schedules. 

10.5  Schedule  risk.  The  schedule  shall  include  a  description  of  the  approach  that  will 
be  taken  to  limit  the  schedule  risks  identified  as  a  result  of  the  contractor' s  risk 
assessment.  Risk  shall  be  defined  considering  impact  on  cost  and  technical  performance 
and  assessing  the  probability  of  schedule  change.  Additionally,  technical  performance 
measurement  tasks  and  their  correlation  with  contractual  cost/schedule  elements  permit 
assessment  of  the  program  effort  in  terms  of  the  schedule  as  well  as  cost  of  work 
increments.  As  technical  performance  measurement  tasks,  as  well  as  cost  reviews,  reveal 
potential  impacts  to  the  schedule  these  risks  will  be  identified. 

10.5.1  Schedule  Risk  Assessment  (SRA) .  Optimistic,  pessimistic,  and  most  likely 
durations  for  each  MIPS  activity/task  and  milestone/event  shall  be  provided  as  the  basis 
for  determining  the  probability  of  meeting  schedule  dates.  The  government  will  assess  the 
durations  and  use  an  appropriate  cumulative  probability  (0-100%)  for  the  chosen  milestones 
to  determine  expected  completion  dates. 
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Common  Time  Robbers^ 


Incomplete  work 

A  job  poorly  done  that  must  be  done 
over 

Poor  communications  chaimels 

Uncontrolled  telephone  calls 

Lack  of  adequate  responsibility  and 
commensurate  authority 

Poor  functional  performance  and 
status  reporting 

Changes  without  direct  notification/ 
explanation 

Casual  visitors  and  conversations 

Waiting  for  people 

Failure  to  delegate,  or  unwise 
delegation 

Poor  retrieval  systems 

Lack  of  information  in  a  ready-to-use 
format 

Day-to-day  administration 

Spending  more  time  than  anticipated 
in  answering  questions 

Late  appointments 

Impromptu  tasks 

Having  to  explain  "thinking"  to 
superiors 

Too  many  levels  of  review 
Too  many  people  in  a  small  area 


Misplaced  information 

Record  keeping 

Shifting  priorities 

Indecision  or  delaying  decisions 

Procrastination 

Setting  up  appointments 

Too  many  meetings 

Monitoring  delegated  work 

Unclear  roles/job  descriptions 

Uimecessary  crisis  intervention 

Need  to  get  involved  in  details  to  get 
job  done 

Not  enough  proven  or  trustworthy 
managers 

Vague  goals  and  objectives 

Too  many  people  involved  in  minor 
decision  making 

Lack  of  technical  knowledge 

Lack  of  authorization  to  make 
judgment  decisions 

Unreasonable  time  constraints 

Lack  of  commitment  from  higher 
authorities 

Too  much  travel 

Lack  of  adequate  project  management 
tools 
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Poor  functional  communications/  writ 
ing  skills 

Inability  to  relate  to  peers  in  a  personal 
way 

Rush  into  decisions /beat  the  deadline 

Lack  of  reward  ("a  pat  on  the  back  can 
do  wonders") 

Expecting  too  much  from  one's  staff 
and  oneself 

Going  from  crisis  to  crisis 

Conflicting  directives 

Fire  drills 

Lack  of  privacy 

Lack  of  challenge  in  job  duties 

Bureaucratic  roadblocks  ("ego") 

Empire-building  line  managers 

Too  much  work  for  one  person  to  handle 
effectively 

Excessive  paperwork 

Lack  of  clerical/  administrative  support 

Workload  growing  faster  than  capacity 


Dealing  with  unreliable  subcontractors 

Personnel  not  willing  to  take  risks 

Demand  for  short-term  results 

Lack  of  long-range  plaiming 

Being  overdirected 

Overreacting  management 

Poor  lead  time  on  projects 

Documentation  (reports /red  tape) 

Large  number  of  projects 

Inadequate  or  inappropriate  require 
ments 

Desire  for  perfection 

Lack  of  dedication  by  technical  experts 

Lack  of  project  organization 

Constant  pressure 

Constant  interruptions 

Project  budget  problems 

Shifting  of  functional  personnel 

Lack  of  qualified  manpower 


_ ENDNOTES _ 

Harold  Kerzner,  Project  Management,  Van  Norstand  Reinhold,  New  York,  NY,  1998,  Chapter  6. 
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APPENDIX  C 

GLOSSARY 


ACQUISITION  STRATEGY  —  A  busi¬ 
ness  and  technical  management  approach 
designed  to  achieve  program  objectives 
within  the  resource  constraints  imposed.  It 
is  the  framework  for  plaiming,  directing, 
contracting  for,  and  managing  a  program. 
It  provides  a  master  schedule  for  research, 
development,  test,  production,  fielding, 
modification,  postproduction  manage¬ 
ment,  and  other  activities  essential  for  pro¬ 
gram  success.  Acquisition  strategy  is  the 
basis  for  formulating  functional  plans  and 
strategies  [e.g.,  test  and  evaluation  master 
plan  (TEMP),  acquisition  plan  (AP),  com¬ 
petition,  prototyping,  etc.]. 

ACTIVITY  —  A  task  or  measurable 
amount  of  work  to  complete  a  job  or  part  of 
a  project. 

ACTUAL  COST  OF  WORK  PER¬ 
FORMED  (ACWP)  —  The  costs  actually 
incurred  and  recorded  in  accomplishing 
the  work  performed  within  a  given  time 
period. 

ARROW  DIAGRAM  METHOD  (ADM) 

—  A  type  of  network  diagram  that  labels 
the  activities  on  the  lines  connecting  nodes. 

BAR  CHART  —  The  detailed  graphical 
working  plan  of  a  part  providing  sequence 
and  time  for  the  job  scheduled  ahead  and 
progress  to  date. 

BUDGETED  COST  OF  WORK  SCHED¬ 
ULED  (BCWS)  —  The  sum  of  the  budgets 
for  all  work  (work  packages,  planning  pack¬ 


ages,  etc.)  scheduled  to  be  accomplished 
(including  in-process  work  packages),  plus 
the  amount  of  level  of  effort  and  appor¬ 
tioned  effort  scheduled  to  be  accomplished 
within  a  given  time  period.  (Planned  V alue) 

BUDGETED  COST  OF  WORK  PER¬ 
FORMED  (BCWP)  —  A  measurement  of 
work  performed  in  cost/ schedule  control 
systems  criteria  (C/SCSC)  terminology. 
BCWP  is  a  measurement  of  work  per¬ 
formed  as  compared  to  the  original  plan. 
(Earned  Value) 

BUDGETING  —  The  process  of  translat¬ 
ing  resource  requirements  into  a  funding 
profile. 

CRITICAL  PATH  METHOD  (CPM)  —  A 

technique  that  aids  understanding  of  the 
dependency  of  events  in  a  project  and  the 
time  required  to  complete  them.  Delayed 
activities  that  have  an  impact  on  the  total 
project  schedule  are  critical  and  said  to  be 
on  the  critical  path. 

EARNED  VALUE  MANAGEMENT  SYS¬ 
TEM  (EVMS)  —  An  integrated  manage¬ 
ment  system  that  coordinates  work  scope, 
schedule,  and  cost  goods  and  objectively 
measures  progress  toward  these  goals.  It 
is  based  on  an  industry-developed  set  of 
32  guidelines  adopted  for  use  by  DoD  in 
1999  for  evaluation  of  contractor  manage¬ 
ment  systems.  A  complete  listing  of  the 
guidelines  is  contained  in  DoD  5000. 2-R, 
Appendix  VI. 
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FLOAT  —  The  period  of  time  that  an  activ¬ 
ity  may  be  delayed  without  becoming  a 
critical  activity.  Also  known  as  slack  or 
path  float/ slack. 

FREE  FLOAT  —  The  float  that  a  single 
activity  can  experience  without  affecting 
any  other  activity. 

GANTT  CHART — A  graphic  portrayal  of 
a  project  which  shows  the  activities  to  be 
completed  and  the  time  to  complete  repre¬ 
sented  by  horizontal  lines  drawn  in  pro¬ 
portion  to  the  duration  of  the  activity.  Some 
Gantt  charts  will  be  able  to  show  the  float 
for  the  activity. 

INTEGRATED  MASTER  PLAN  (IMP)  — 

An  event-based  plan  that  depicts  the  over¬ 
all  structure  of  the  program  and  the  key 
processes,  activities,  and  milestones.  It  de¬ 
fines  the  accomplishments  and  criteria  for 
each  event  in  the  plan. 

INTEGRATED  MASTER  SCHEDULE 
(IMS)  —  The  detailed  task  and  timing  of 
the  work  effort  in  the  IMP.  A  networked 
schedule  that  identifies  all  IMP  events, 
accomplishment,  and  criteria,  and  the  ex¬ 
pected  dates  of  each. 

INTEGRATED  PRODUCT  AND  PRO¬ 
CESS  DEVELOPMENT  (IPPD) — A  man¬ 
agement  technique  that  simultaneously 
integrates  all  essential  acquisition  activi¬ 
ties  through  the  use  of  multidisciplinary 
teams  to  optimize  the  design,  manufactur¬ 
ing,  and  supportability  processes.  IPPD 
facilitates  meeting  cost  and  performance 
objectives  from  product  concept  though 
teamwork  through  Integrated  Product 
Teams  (IPTs). 


INTEGRATED  PRODUCT  TEAM  (IPT) 

— Team  composed  of  representatives  from 
all  appropriate  functional  disciplines  work¬ 
ing  together  to  build  successful  programs, 
identify  and  resolve  issues,  and  make 
sound  and  timely  recommendations  to  fa¬ 
cilitate  decision  making.  There  are  three 
types  of  IPTs:  overarching  IPTs  (OIPTs) 
focus  on  strategic  guidance,  program  as¬ 
sessment,  and  issue  resolution;  working 
IPTs  (WIPTs)  identify  and  resolve  program 
issues,  determine  program  status,  and  seek 
opportunities  for  acquisition  reform;  and 
program-level  IPTs  focus  on  program  ex¬ 
ecution  and  may  include  representatives 
from  both  government  and  after  contract 
award  industry. 

LINE  OF  BALANCE  (LOB)  —  A  graphic 
display  of  scheduled  units  versus  actual 
units  produced  over  a  given  set  of  critical 
schedule  control  points  on  a  particular  day. 

MASTER  PROGRAM  SCHEDULE 
(MPS) — The  top-level  schedule  for  the  pro¬ 
gram.  It  is  prepared  by  the  government 
and  includes  all  policy  and  contractual 
events /activities.  It  is  derived  from  the 
Program  WBS  and  provides  the  baseline 
for  all  subordinate  schedules.  It  some¬ 
times  is  called  the  program  structure/ 
schedule. 

MILESTONE  (MS)  —  The  point  when  a 
recommendation  is  made  and  approval 
sought  regarding  starting  or  continuing 
(proceeding  to  next  phase)  an  acquisition 
program.  Milestones  are:  0  [Approval  to 
Conduct  Concept  Studies],  I  [Approval  to 
Begin  a  New  Acquisition  Program],  II  [Ap¬ 
proval  to  Enter  Engineering  &  Manufac¬ 
turing  Development  (EMD)],  and  III  [Pro¬ 
duction  or  Fielding /Development  and 
Operational  Support  (PF/DOS)  approval]. 
A  significant  event  that  marks  certain 


80 


progress,  such  as  completion  of  a  phase  of 
the  project. 

MILESTONE  CHART  —  A  graphic 
portrayal  of  a  program/ project  that  shows 
the  events  to  be  completed  on  a  timeline. 

NETWORK  SCHEDULE  —  A  scheduling 
technique  that  provides  the  means  for  de¬ 
fining  task  relationships  and  relationship 
lags.  These  may  include  such  precedence 
relationships  as  "Start  to  Start,"  "Finish  to 
Finish,"  and  "Start  to  Finish." 

PERT  —  See  Program  Evaluation  Review 
Technique. 

PERT  Chart — A  graphic  portrayal  of  mile¬ 
stones,  activities,  and  their  dependency 
upon  other  activities  for  completion  and 
depiction  of  the  critical  path. 

PRECEDENCE  DIAGRAM  METHOD  — 

A  network  diagram  in  which  the  activities 
are  labeled  in  the  nodes,  usually  boxes. 

PRODUCTION  SCHEDULES— Chrono¬ 
logical  controls  used  by  management  to 
regulate  efficiently  and  economically  the 
operational  sequences  of  production. 

PROGRAM  EVALUATION  REVIEW 
TECHNIQUE  (PERT)  —  A  technique  for 
management  of  a  program  from  inception 
through  to  completion  by  constructing  a 
network  model  of  integrated  activities  and 
events  and  periodically  evaluating  the 
time/ cost  implications  of  progress. 

RESOURCE  LEVELING  —  A  process 
whereby  resources  are  sorted  out  among 
tasks  and  activities  to  identify  and  avoid 
conflicts  between  scheduling  and  avail¬ 
ability. 


RISK  —  A  measure  of  the  inability  to 
achieve  program  objectives  within  defined 
cost  and  schedule  constraints.  Risk  is  asso¬ 
ciated  with  all  aspects  of  the  program,  e.g., 
threat,  technology,  design  processes,  work 
breakdown  structure  (WBS)  elements,  etc. 
It  has  two  components:  the  probability  of 
failing  to  achieve  a  particular  outcome  and 
the  consequences  of  failing  to  achieve  that 
outcome. 

RISK  MANAGEMENT  —  All  plans  and 
actions  taken  to  identify,  assess,  mitigate, 
and  continuously  track,  control,  and  docu¬ 
ment  program  risks. 

SCHEDULE  —  Series  of  things  to  be  done 
in  sequence  of  events  within  given  period; 
a  timetable. 

SCHEDULE  RISK  —  The  risk  that  a  pro¬ 
gram  will  not  meet  its  acquisition  strategy 
schedule  objectives  or  major  milestones 
established  by  the  acquisition  authority. 

SCHEDULE  VARIANCE  —  A  metric  for 
the  schedule  performance  of  a  program.  It 
is  the  algebraic  difference  between  earned 
value  (BCWP)  and  plaimed  value  (BCWS) 
(Variance  =  BCWP  -  BCWS).  A  positive 
value  is  a  favorable  condition  while  a 
negaive  value  is  unfavorable. 

SCHEDULING — The  prescribing  of  when 
and  where  each  operation  necessary  to  the 
manufacture  of  a  product  is  to  be  per¬ 
formed. 

WORK  BREAKDOWN  STRUCTURE 
(WBS)  —  An  organized  method  to  break 
down  a  project  into  logical  subdivisions  or 
subprojects  at  lower  and  lower  levels  of 
details.  It  is  very  useful  in  organizing  a 
project.  See  MIL-HDBK  881  for  examples 
ofWBSs. 
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